Fix for bugfix: old_offset==0 is valid, silly
Fix for merge file delete & frozen fold races

One the keydir is frozen during a fold, it's possible for a
parallel merge to delete files needed for the fold in a race
with opening them.

The fix is to add the concept of a fold iterator generation
number to the NIF and to expose it via the keydir info call.
It's safe to delete files from a successful merge operation
if there is no fold happening or if the current fold is of
a newer generation than the generation saved when the merge
finishes.

Also added: turning on the setuid file permissions bit of
merge input files that are marked pending for delete.  The
setuid bit is then checked & filtered when appropriate.
Setuid data files are deleted at open time by a `read_write`
caller.
Fix a race between opening & closing

If an open and a close race, it's possible for the opening
process to "not see" the active writing file because it's
locked by the still-closing process and therefore isn't
visible to bitcask:readable_files().

Fix: Close the writing file and release the write lock first.
Then release the keydir.
Fix race with multiple merges and single put

In the real world, 2 retries is usually sufficient.  In the
world of QuickCheck, however, QC can create some diabolical
races, so use a diabolical number of retries for do_put(): 100.

Also, fix a typo in do_put() recursion last arg.
Model fix for scheduling pathology that causes open -> {error,timeout}

If we manage to get a timeout when opening a database, there's a
pathological scheduling delay that is causing starvation.  Expose
the starvation by not considering {error, timeout} a success.

Use an `open_timeout` that should be large enough to push beyond
any pathological run schedule that QC ought to create.
Fix merge lock leak when merge1() cannot open the keydir.
Fix races inside scan_key_files()

The scan_key_files() function is used by both keydir_open() and
merge1().  In the former case, any file open problem should be
fatal; in the latter case, there is no harm if a file cannot be
opened because of an honest race with the deferred deletion
from an earlier merge.

Added a query to the merge deferred delete server to be able
to poll the length of its queue.

Also fix a couple of unused var compiler warnings in EUnit
tests.
Fix race with QC model and bitcask_lockops:read_lock_data()

There is an honest race between a creator of a lock file
and someone reading it: the reader may see a file of zero bytes.
This race should be fixed with an atomic lock file creation,
that fix should only be needed for the case where a lock creator
crashes immediately after creating the lock file but not writing
the file contents.

Allow the model to detect that the zero-byte-lock-file race
happened and to ignore it.
Fix the compare-and-swap semantics of NIF's put_int() old_file_id

My previous implementation of the compare-and-swap semantics of
bitcask_nifs_keydir_put_int() was flawed: if the key didn't exist
in the keydir, then the compare-and-swap semantics signalled by
old_file_id != 0 was not being enforced.
Add newest_tstamp to NIF's per-file statistics
Bugfix: free keydir->pending_awaken if != NULL
Avoid using realloc if keydir->pending_awaken is NULL
Add tracking of newest tstamp to bitcask's file info

Used in conjunction with the BIF's bitcask_fstats_entry
tracking of newest_tstamp, we no longer allow fold to
operate on any data file that may have a timestamp that
matches the timestamp at the time the merge started.

Edit summarize() to create #file_status records that
includes the newest_tstamp data.

Add an artificial time adjustment command, incr_clock, to
bitcask_eqc.erl.  This is used in conjunction with

Add 1.1 second sleeps to EUnit tests that call merge.
I suppose it's possible to use the same time fudging
mechanism that bitcask_eqc.erl uses, but I'm not to avoid
using stateful stuff -- cleaning up after twiddling app
env vars is a hassle and can cause cascading EUnit test
failures if you're not really careful.