Update suasync to 1.3.2.
Remove the need for explicit row locks when allocating UIDs.

The existing code with explicit row locks exhibited very poor
performance, and also prevented multiple TSDs from allocating
UIDs concurrently.

The new approach consists in:
  1. Performing an atomic increment to grab a new UID.
  2. CAS'ing (CompareAndSet) the reverse mapping (uid => name)
  3. CAS'ing the forward mapping (name => uid)

If we die after step 1, we waste an UID.  If we die after step 2,
we just end up with an orphaned reverse mapping (harmless).  When
two TSDs race to assign a UID to the same name, one of them will
fail to CAS the forward mapping at step 3, and will retry to find
the UID assigned by the winning TSD.  When that occurs, the only
net consequence is that a UID will have been wasted by the losing
TSD, whereas the previous implementation wouldn't waste one when
this happened.  The 'uid fsck' command can easily detect orphaned
or wasted UIDs, and we could conceivably put them on some kind of
a free list in the future to re-allocate them.

If two TSDs are running side-by-side, and one uses the old method
while the other uses the new lock-less method, things still work
as expected.  There are two possible scenarios:
  - Old TSD goes first, locks the MAXID row, and does its thing.
    The new TSD will have to wait until the row lock is released
    for its atomic increment to go through.
  - The new TSD goes first, atomically increments the MAXID row,
    and does its thing.  The second TSD locks the MAXID row and
    proceeds to allocate its own ID concurrently.
Fix helper class used in StdDev test, tighten error margins and add tests.

Signed-off-by: Benoit Sigoure <tsunanet@gmail.com>
Encode integer values on a variable number of bytes.

The design always supported this, and the read-path already supports
reading those, but the write path never really bothered and always
wrote all integer values on 8 bytes no matter what.
Add an API to store double-precision floating point values.
Fix compaction bug: flush compaction queue if it's too old.

The compaction queue needs to be flushed if either it's grown too
large or it's been too long since the last flush.  That second
condition wasn't implemented properly because the timestamp that
tracks the time at which we last flushed was never set and always
remained 0.  This would only impact very low-traffic TSDs that
never manage to exceed the threshold on the size of the queue.

Thanks to Brent Evans for spotting and reporting this bug.
Simplify the condition under which we flush the compaction queue.

This code is equivalent to what we had before.  Given the constants
in the code, we were only flushing based on the queue size when one
of those two conditions was true:
  - The size of the queue is bigger than 100
  - The size of the queue is bigger than 18000
Which obviously can be simplified as checking only against 100.

Thanks to Brent Evans for pointing this out.
Don't bother flushing the compaction queue based on time.

If someone is writing to less than 100 rows ever then compactions
probably don't actually matter (and can always happen lazily during
read accesses).

Thanks to Brent Evans for the suggestion.
Fix #228 introduced by variable length encoding where integer values stored on
single bytes in HBase were being cast to unsigned ints in
RowSeq.extractIntegerValue. Removed the bitmask and now single bytes are
returned correctly.

Signed-off-by: Chris Larsen <clarsen@euphoriaaudio.com>
Added timezone query paramter