Fix up the comments associated with __rec_page_modified, it's all about
the child page, and the header comment on WT_REF states was wrong now
that checkpointing threads do their own work.
typo
Re-structure chunks of __bt_evict.c to make checkpoints outside of the
eviction server thread work.  I think I'm fixing two problems:
    First, the cache->disabled_eviction handling isn't sufficient (we
were emptying the LRU queue, but we weren't waiting for it to drain).
If a thread of control took a buffer off the LRU eviction queue and went
to sleep, it would be possible for it to race with a thread of control
during the internal-page phase of a checkpoint, and we can't allow any
pages at all to be written after the internal-page checkpoint phase
starts.   The fix is to contact the eviction server at the start of the
internal-page phase of a checkpoint and have it wait for the LRU queue
to drain.
    Second, we can't discard any page with a modified structure during
the internal-page checkpoint phase because that can race with the
checkpoint threads looking at the WT_REF structure for the page being
discarded, in other words, there's a state change in the internal page
just when the internal page is being read.

I also changed it so we don't turn off writes for the entire cache when
doing the internal-page phase of a checkpoint, we only need to turn off
writes for the file being checkpointed.

Move WT_SYNC_XXX flags into dist/flags.py, they're no longer specific
to an eviction server operation, they only place you see them all is in
the __wt_bt_cache_flush() function.

Reference #419.
Another set of changes to make checkpoints outside of the eviction
server thread work.  The last set of changes had (at least) two
problems:

First, the test to avoid selecting a dirty page for eviction was
insufficient.  It appeared in __evict_walk_file, which is before
eviction has exclusive access, the test should still appear there to
avoid selecting pages there is no hope of evicting, but should also
appear in __rec_review after the page is locked down to ensure no pages
modified after selection, but before final review, are written.

Second, the test to avoid selecting a dirty page for eviction wasted
performance because we couldn't select a page ever considered for
modification (regardless of whether or not it was actually modified),
because racing with the checkpoint thread reviewing an internal page
that referenced the evicted page could drop core when the evicted page's
modification structure disappeared.

This set of changes adds a test in __rec_review to resolve the first
problem.

The second problem is trickier, and messes with page states (oh joy!).
The key is to inform page reconciliation if it's being called by the
eviction server thread or a checkpoint thread.  In the case of being
called by the eviction server thread, any child page of an internal page
that's in the WT_REF_LOCKED state is in a stable, in-memory state,
because the calling thread set the WT_REF_LOCKED state.  In the case of
being called by the checkpoint thread, any child page of an internal
page that's in the WT_REF_LOCKED state is in a temporary state because
it's been locked by eviction.  It will either be evicted (and the page
state reset to WT_REF_DISK), or skipped (and the page state reset to
WT_REF_MEM).  Regardless, the reconciliation within the checkpoint
thread has to wait on that state change.

This is all built on top of a set of flags passed into reconciliation,
which additionally offers better control over skipping updates on a
page.  We now explicitly flag if reconciliation should (1) quit early
if unable to entirely clean a page, set by the eviction code, (2) panic
if it's unable to entirely clean a page, set by sync during file close
and by salvage, or (3) not worry about it, set by the checkpoint passes.

Reference #419.
Simplify WT_PANIC_XXX and friends.

I needed a return version, which made 3, but we only have 2 cases: (1)
one that returns WT_PANIC without any error value for the associated
message, and (2) one that doesn't return WT_PANIC (ever), but does have
an error value for the associated message.

Case #1 is now WT_PANIC_ERR, case #2 is WT_PANIC_RETX, and that leaves
WT_PANIC_ERRX for a version that doesn't return WT_PANIC (ever) but does
have an error value for the associated message, and WT_PANIC_RET for a
version that returns WT_PANIC and has an error value for the associated
message, if we ever need them.
If there's an inserted record, but we can't read the update, it doesn't
exist for us.   Reference #419.
If the file is being checkpointed, the checkpoint's reconciliation of
an internal page might race with us as we evict a child in the page's
subtree.

One half of that test is in the reconciliation code: the checkpoint thread
waits for eviction-locked pages to settle before determining their status.
The other half of the test is in eviction: after acquiring the exclusive
eviction lock on a page, confirm no page in the page's stack of pages
from the root is being reconciled in a checkpoint.  This ensures we
either see the checkpoint-walk state in eviction, or the reconciliation
of the internal page sees our exclusive lock on the child page and waits
until we're finished evicting the child page (or give up if eviction
isn't possible).

Reference #419.
Change reconciliation to yield immediately after determining the state of a
child page in diagnostic runs, and to save the previous state of the page in
the WT_RECONCILE structure.  This is what I've been using to debug #419.
typo
Merge branch 'develop' into dirty-disable
Merge branch 'develop' into dirty-disable

Conflicts:
	src/btree/bt_evict.c
Wait for LRU eviction to complete in the checkpoint thread, without waiting for the eviction server.
We don't need to disable eviction of dirty pages now that we're disabling all eviction in the subtree being checkpointed.
Remove disabled code and rename "writes_disabled" now that all eviction is disabled in the subtree of an internal node being checkpointed.
Fix a comment, compaction no longer goes through the evict-file call.
Use the standard panic calls if we get a sync operation we don't expect.
No real changes.
Back out a change: don't queue dirty pages for eviction during a checkpoint.  It's very unlikely that we'll find a dirty page that we can evict (it would have to be an internal node with no children, ahead of the checkpoint).
Merge pull request #423 from wiredtiger/dirty-disable-mjc

Tweaks to the dirty-disable branch based on review.
Merge branch 'develop' into dirty-disable

Conflicts:
	src/btree/bt_evict.c
Merge pull request #420 from wiredtiger/dirty-disable

Fixes for races between checkpoints and eviction.