Log a little more debug when flushing keys
New memory management feature: NDS "high-water mark"

While you want to make sure your Redis doesn't take up too much memory, you
may occasionally need to "burst" above that level.  This is now what
nds-watermark does -- Redis will *try* to keep memory usage under the
watermark, but will use memory up to maxmemory before denying writes.
Yet another rework of the NDS-enabled freeMemoryIfNeeded()

We're doing a couple of things here:

1) No longer busy-wait on an NDS flush completing.  This was a dumb idea
   born out of necessity when the only time we might end up doing a flush
   was once we were already at maxmemory.  Now, with nds-watermark, you
   should never end up in this situation because we'll be starting to try
   and free memory much earlier, giving flushes a chance to complete long
   before we ever hit maxmemory (assuming sane values for nds-watermark and
   maxmemory).

2) If our search for an old key to free ends up giving us a dirty key, we do
   a linear scan of *all* the keys looking for *any* key that's clean to
   discard.  This will be relatively slow, and doesn't take into account
   LRU, but this really is a last-ditch attempt to avoid an error condition
   -- with this change, we never throw an OOM until *every* key in memory is
   dirty.  At that point, sucks to be you, but you're gonna get DENIED.
   Gimme moah memories.

One thing to note: there's no point making the algorithm to find the LRU key
take into account dirty keys; by definition, the LRU key is the one
*least* likely to be dirty.  So there's no need to make anything more
complicated.
Logic improvements in freeMemoryIfNeeded
Log more around snapshots
Remove the old key globally, not per-DB

This prevents a DB which only has one key from repeatedly evicting its only key, when there
are plenty of less-used keys in other DBs that don't get kicked out first.
Debug logging, micro-optimisation, and memory leak prevention
Whitespace
Fix ref to dict
*cough*
Fix up freeMemoryIfNeeded some more so the whole test suite passes
Implement TTL storage in NDS

The remaining big ticket missing feature from NDS... now it's done.  Someone
wanted it, I decided to get my hack on.
Storing big numbers in small variables is a recipe for disaster
Update liblmdb to 0.9.8 (0f842a2)
Cleanup NDS before we fork
Handle EINVAL from mdb_cursor_open more appropriately
Validate key names in line with MDB's requirements

Redis, by default, allows pretty much any byte sequence to be a key
(including the empty string), up to (reputedly) 2^31 or so octets.

MDB is not so forgiving.  It limits keys to 511 bytes, and pitches a
not-so-tiny fit on attempts to manipulate a value whose key is the empty
string.  So, in the interests of sanity, I've gone through and found
(hopefully) every command which can take one or more keys as arguments, and
caused them all to return errors on attempts to specify an invalid key.
Don't open a transaction more than once

It turns out that MDB has a requirement that only one transaction may
be active at a time per thread.  This means that when we have a txn
open in, say, a walker, we can't then open another one to read the key
to check its expiry.  The effort involved in making this work properly
is significant, and involves refcounting and checking things and is
potentially a bug-ridden mess, but there aren't any other alternatives
I could think of (suggestions appreciated).

Now, at least, we won't get MDB_BAD_RSLOT errors on KEYS.
Add a new 'nds_usec' entry in the NDS info section

This counts the amount of time spent doing NDS-specific things --
essentially, it's the additional overhead of running NDS that wouldn't be
incurred if you were running regular Redis.
Implement nds-keycache

This is a trialled performance optimisation, to try and avoid hammering disk
all the time if we're just going to be told that the key doesn't exist
there, either.