WiredTiger can walk long update chains for hot rows.

michael.cahill, when chasing WT-3739 (a YCSB, zipfian, r50/u50 workload), I realized we're walking update chains with 80K+ items on them. The problem is __wt_txn_update_check(), it walks the entire update chain looking for a possible collision.

My guess is we've made this worse by adding WT_CURSOR.modify, because chains can get roughly 10x longer before we'll evict the page because of footprint.

It seems to me we could check just the first update entry if the update chain has never been modified by a non-snapshot transaction (probably requires a flag byte in the WT_UPDATE structure, or a flag bit stolen from the WT_UPDATE structure's type?), or we could just set a flag on the tree if it's ever modified by a non-snapshot transaction (that should clear us with MongoDB?).

Anyway, I'm tossing this to you because I think it's a pretty simple fix for hot rows, but I may be misunderstanding the issues.