Change how snapshot handles flushing of write buffer

[dcoutts]

Currently, snapshot will mutate the given handle by flushing the write buffer, before trying to take a snapshot of all the runs.

This has the effect of invalidating all blob references, which is surprising and does not correspond to the spec/model.

A plausible solution would be to do it like this: flush the write buffer to a new run, but do not modify the table handle to use that new run. Leave the table handle as-is (thus not invalidating blob refs). Then save all the runs (including the one flushed from the write buffer) into the snapshot.

Difficulties: flushing one more run may necessitate kicking off more merges, otherwise it would leave an over-full level 1. Perhaps this is ok to do for a snapshot, and the merging can be performed upon restoring the snapshot. In other words don't enforce (or explicitly relax) the levels shape invariant (which checks the number of runs in a level) for a snapshot, but enforce it upon restoration by starting the appropriate merges.

In addition, the current snapshot code modifies the table handle state before it checks if the snapshot name is already taken or not, so even if snapshot fails then there are state changes that invalidate the blob references.

The code should be adjusted to open the snapshot file first (thus doing the duplicate name check) and then do the rest of the work.

When this is done, the state machine model can be simplified. See Database.LSMTree.Model.Normal.Session which references this issue.

[jorisdral]

...

In addition, the current snapshot code modifies the table handle state before it checks if the snapshot name is already taken or not, so even if snapshot fails then there are state changes that invalidate the blob references.

The code should be adjusted to open the snapshot file first (thus doing the duplicate name check) and then do the rest of the work.

...

This part is already done