rename RebalanceAccess->RangeManager
Merge pull request #52 from tobstar87/rangeaccess

rename RebalanceAccess
Always update timestamp cache. This correctly resolves our final commit
timestamp as we send writes to various nodes as part of a distributed
txn.

Renamed read_timestamp_cache to just timestamp_cache and updated comments
leading reader to believe it's just for reads!
Added a test to verify sort ordering for binary encoded MVCC metadata
keys and versioned value keys.
Merge pull request #57 from cockroachdb/spencerkimball/range-key-tests

Added a test to verify sort ordering for binary encoded MVCC metadata
Add another test case.
Merge pull request #58 from cockroachdb/spencerkimball/range-key-tests

Add another test case.
Merge pull request #56 from cockroachdb/spencerkimball/delete-range-to-read-timestamp-cache

Always update timestamp cache. This correctly resolves our final commit
compute split key for range splitting
add TODOs
Merge pull request #50 from tobstar87/rsplit

compute split key for range splitting
Move from dealing with just transaction ID to using the full transaction
struct in write intents and in request / response headers.

Cleaned up some code in MVCC that was unnecessarily complex and introduced
concept of transaction epochs for Put() and for ResolveIntent(). Transaction
epochs start at 0 and are incremented every time a transaction is retried.
Transactions are retried (instead of aborted) in the event that a value is
encountered within the "window of uncertainty" between RequestHeader.Timestamp
and RequestHeader.MaxTimestamp, or in the case of an SSI transaction, if
the final transaction timestamp is not equal to the initial transaction
timestamp.

Typically, when a transaction has to restart, it covers all of the same
keys on writes and increments the intents' epochs accordingly. However,
if there's conditional logic in the transaction, it might end up skipping
some keys which were written the previous run--those earlier intents should
then not be committed when the intents are resolved after txn commit.
Updated contract between RequestHeader and ResponseHeader for specification
of Transaction and Timestamp. In particular, the Transaction object is now
not supplied in the Response except for in the case of BeginTransaction
and HeartbeatTransaction requests.

Clarified the comments for ResponseHeader to indicate that the
request Timestamp must be continually upgraded to be the maximum
of all response Timestamps.
Fixes and additional tweaks to unittests and a new MVCC unittest.

 - Use write batch for all multi-put ops in MVCC.

 - Delete previous intent versions when overwriting an intent with
   a newer timestamp within same transaction. This can happen on
   transaction retries.

 - When resolving an intent, make sure to properly update the intent
   value's timestamp if the commit timestamp is different from the
   original timestamp the value was written at.