Add a minor comment about what happens if the insert races.
Closes #690.
The wrapped-generation check is only called from serial functions, we know
the page's modify structure is set.
Fix a comment: we no longer track the page's write generations, this
comment should have been fixed in 1027c6de96.
Test the WT_BTREE.modified value before setting it, it's probably a hot
cache line.  (This is the only real change here, the rest is semantic
sugar.)

Set the WT_BTREE.modified value after we've flushed the insert/update
information (I don't think this is a bug, but it feels cleaner).

Flip the default for page-dirty: by default, mark both the tree and the
page dirty.  There are 3 places we have reason not to mark the tree
dirty, add comments for them; clean up the places we were setting the
WT_BTREE.modified value explicitly instead of calling the right modify
function.  This doesn't change the previous behavior, but it's safer --
I want people to have to search for some way to NOT dirty the tree, in
the rare case that's useful.
Regularize a couple of comments.
It's possible to race when deciding if we're making the first update to
a page, which could mess up the cache statistics.   Use the serial lock
to protect that test (specify if we already hold that lock when we call
the __wt_page_modify_set/__wt_page_only_modify_set functions).
Don't bother allocating a WT_PAGE_MODIFY structure if we're not going
to use it.
It doesn't matter if we mark the page or the tree dirty first; collapse
the three page-modify functions back into a pair of functions, one of
which marks the page dirty, the other of which calls the first and then
marks the tree dirty.
Get rid of the page disk generation, and use a write generation of 0 to
flag clean pages.  Use atomic add and compare-and-swap instructions to
mark a page dirty/clean.

This change means we no longer have to hold the serial lock when first
marking a page dirty, back out that change from a few revisions ago.

I'm suspicious this might fix another one of the lurking bugs where our
cache statistics are occasionally wrong: I'm pretty sure the code in
__rec_write_wrapup() to decrement the cache footprint when a page was
marked clean, could race, if the instructions after reading the page's
memory footprint were reordered.

Reorder the WT_PAGE_MODIFY structure, dropping it to 64B.
whitespace
__sync_add_and_fetch returns the new value, not the old value, fix the
test for switching from clean to dirty.
Fix a comment for clarity.
Don't do a function call just to detect the common case of there not being
additional updates for this row.
Whitespace/KNF
Merge pull request #695 from wiredtiger/generation_cleanup

Cleanup of tracking write and disk generation numbers. We no longer need to track disk generations.
Update comment.
Semantic sugar.

Inline __wt_cache_bytes_dirty() and __wt_cache_pages_dirty(), there's no
policy of not directly accessing WT_CACHE fields, and that's all they do.

Remove comments about 8B vs. 4B atomic read/write and "special" code in
__wt_cache_pages_inuse() and __wt_cache_bytes_inuse(), WiredTiger
requires 8B atomic read/write, the comments no longer make any sense.
Merge branch 'develop' into offsetsearch2