Added 3 methods to KCVS.
add Cassandra adapters implemention of getSlice(List<StaticBuffer>, ...) + test
add HBase implemention of getSlice(List<StaticBuffer>, ...) + test
Astyanax getKeys(SliceQuery)/getKeys(KeyRangeQuery) implementations
Cassandra Thrift getKeys(SliceQuery)/getKeys(KeyRangeQuery) implementations
Embedded Cassandra getKeys(SliceQuery)/getKeys(KeyRangeQuery) implementations
HBase getKeys(SliceQuery)/getKeys(KeyRangeQuery) implementations + small changes in Cassandra ones
add missing getKeys({KeyRange,Slice}Query, StoreTransaction)
merge with master
refactor MetricInstrumented{Store, Iterator} and add missing getKeys(...) methods
fix Astyanax getKeys(...) dispatch when SliceQuery is null
add getKeys(SliceQuery) test for all of the backends
add getKeys(KeyRangeQuery) test case
Merge remote-tracking branch 'origin/master' into kcvsiter
WIP on locking refactoring

Do not use this commit.  It still has a lot of reimplementation,
refactoring, and test cleanup remaining to be done.  The new lock
class names are probably all going to change, too.
Refactoring ConsistentKeyLocker tests

I've reduced what was previously a couple dozen lines of boilerplate
EasyMock stubbing and setup into a set of five setup-helper methods
that model conceptual primitives in EasyMock, like
"recordSuccessfulLocalUnlock()", which internally records expectations
with EasyMock that the locker will make a timestamp call followed by a
call to the local lock mediator using that timestamp (order matters).

This is definitely cleaner from a design point of view.  However, I'm
not sure it's actually a practical improvement over copying
boilerplate.  It seems a lot harder to figure out what EasyMock
failures mean when the expectations involved in the failure are
scattered across a bunch of little helper methods.  Still
experimenting...
Locking refactoring WIP

In the middle of implementing-testing lock checking

This commit is part of a destructive refactoring effort.  Don't use
it.
Adding basic lock delete tests and impl

This is another refactoring commit.  The locking code is still
unstable and unusable in this commit.
Hooked up new locking code to legacy interface

Added some ugly glue code between the newly simplified locking
interface and the legacy graphdb ConsistentKeyLockStore/Transaction
interface.  Still needs some cleanup, and expected value slices won't
retry or gracefully handle errors.  In-memory and embedded Cassandra
lockkeycolumnvaluestoretest classes passed, but there are probably
still bugs at this stage.
Hacking ConsistentKeyLockStore/Txn

Fixes and kludges in equal measure around ConsistentKeyLockStore and
ConsistentKeyLockTransacton.  This commit focuses on the glue code
between BackendTransaction and the new locking implementation.
Expected values checking still needs refactoring.

* Made the new locking code consider only the earliest expected value
  for any give set of calls to acquireLock(key, column, expectedValue,
  tx) where only expectedValue changes and the other arguments are the
  same between calls

* Fixed ConsistentKeyLockStore using the same backing store for both
  data and locks