Add a tail pointer to hlld_set_list
Use setmgr_set_size instead of hset_size which is not thread safe
First pass at a new MVCC architecture

The old MVCC architecture was based on having multiple concurrent
'versions'. Each version is associated with an ART tree, and
potentially a set that should be deleted. The vacuum thread
would then opportunistically clean old versions and delete old sets.
The reads would always be against the latest version in a non-blocking
manner.

The main difficulty with this is that the creation of a new version
was expensive, and grows more so as the number of sets increases.
This is due to the expensive copy of the ART tree.

To avoid this, we now switch to a lighter MVCC architecture.
There are still versions, but now there are only 2 ART trees.
The "primary" and "alternate". Reads against the primary are
non-locked, and done by the clients. The "alternate" is only
accessed by the vacuum thread. Instead, we add a new "delta"
list. This delta list contains sets that have been created
or deleted but not yet merged into the ART tree.

When searching for a set, we search the tree first, and then
the delta list on a miss. The vacuum thread periodically merges
the delta updates into the alternate tree, and atomically swaps
trees.

Once the tree is swapped, it waits until all clients stop using
the old primary, and then merges the delta updates into that
tree as well, so that both trees are in sync.

This new architecture means that creating a new version is
O(1), as we just add a new delta update. It also means the memory
overhead is fixed at 2 ART trees, instead of being largely unbounded.
Minor fix ups for MVCC

Initialize version to 1 and primary_vsn to 0, since otherwise
it is ambiguous which changes have been merged in. The list command
now scans the delta list as well. swap_set_maps version is not set
to min_vsn, but one less than that.
Adding argument to not start vacuum thread, changing interfaces
Adding create_delta_update() to reduce code duplication
Reduce number of log messages
Add a BARRIER delta type to simplify the MVCC system
Tweak the log levels
Adding a pending deletes list

The MVCC system is used to allow 'drop' and 'close' to happen in a
non-blocking way. One side affect of this is that if a client issues
a create/drop/create sequence, the second create can arrive before
the drop has taken place. To make this worse, it's possible that the
create/drop delta updates have been incorporated into the primary set
map. This means it LOOKS like the set does not exist (not in the map or
in the delta set), however the vacuum thread may be waiting on a version
barrier, or applying the delta updates and the set still exists (on
disk). In this case, we still want create to report a delete is in
progress. To support this, we create a lightweight list of pending
deletes that is created before we swap trees, and is cleared after the
vacuum thread does the deletes. This causes a minor slow down in create
since it needs to scan this list, but there should be little contention
for the list.
Flush and unmap threads do a periodic checkpoint to allow the vacuum thread to make progress sooner
Updating changelog