We can't use the underlying KVS keygen function because it can't correct
for records explicitly added (for example, if we WT_CURSOR::insert a new
record "37", then close and re-open the store with "append" configured,
there's no way for the KVS key allocation function to correct for that).
Instead of using keygen, read the last record in the KVS store when we
first try and allocate a new record, and proceed from there.  XXX: This
still isn't quite right, there's still a race where we might get the
"last" record after we've checked to see if the "last" record is being
maintained, but before the inserted record is added.

There's no KVS function that matches WT_CURSOR::update (update the
record if it does exist, fail if it does not exist), so we have to
acquire a lock across a kvs_get/kvs_set pair.

Add a per-data-source lock for the allocated record and get/set call
pair that implements WT_CURSOR::update.
Add a comment: Tony Givargis says future versions of KVS will have a
kvs_replace call that updates IFF the record exists, in which case that
call should replace this locked get/set pair.
Don't use XXX in a comment that's not a bad thing.
Document a couple of existing problems.
update for dist script run.