Elide front-end 3PC for single-shard Tx

Elide front-end 3PC for single-shard Tx

A new method, directCommit, was added to TransactionContext.
In TransactionContextImpl#directCommit, it sends the final ready
BatchedModifications message as before but with a new flag,
doCommitOnReady, set to true. In ShardCommitCoordinator, if
doCommitOnReady is true, it immediately initiates the canCommit
phase without waiting for the CanCommitTransaction message.

In ShardWriteTransaction, if doCommitOnReady is true, it sets a new
similar flag in the ForwardedReadyTransaction message. Similarly,
the ShardCommitCoordinator immediately initiates the canCommit phase.
This code path is executed for read-write transactions as they still
utilize the transaction actor.

In TransactionProxy, when only 1 shard was accessed, it creates a
SingleCommitCohortProxy instance. This class also implements
DOMStoreThreePhaseCommitCohort but the 3 phases are essentially a
no-op with direct commit. The canCommit phase simply waits for the direct
commit Future to complete and returns success (true). If a failure occurs
from the Shard, the exception is propagated to the caller.

For backwards compatibility, we still need the
ThreePhaseCommitCohortProxy even with a single-shard transaction. A
complication with this is that TransactionProxy#ready may not know
immediately if it can do direct commit or not because it may not have the
TransactionContext instance yet due to the async nature of things.
So in either case it still creates a SingleCommitCohortProxy. When it gets
the callback to finally complete the operation, it checks the
TransactionContext to see if it supports direct commit (only
pre-Lithium versions won't). If supported, it calls directCommit, otherwise
readyTransaction. In the SingleCommitCohortProxy, on successful
completion of the ready/direct commit Future, it checks the response
type. If it's an ActorSelection then it needs to do 3-phase commit
so it creates and delegates to a ThreePhaseCommitCohortProxy.

I moved the code in Shard#handleCommitTransaction to the
ShardCommitCoordinator as this is also needed for direct commit. I
also moved the handleForwardedReadyTransaction code into
ShardCommitCoordinator to make it easier to handle direct commit.

Change-Id: I40b04dd5abd24c78709598a5acfc16484e165427
Signed-off-by: Tom Pantelis <tpanteli@brocade.com>