Bug 2038: Ensure only one concurrent 3-phase commit in Shard

Bug 2038: Ensure only one concurrent 3-phase commit in Shard

Added a ShardCommitCoordinator class that ensures there's only one
concurrent 3-phase commit.

The following outlines the new commit workflow:

- On ready, the ShardTransaction creates the dom store cohort and
forwards a new ForwardedReadyTransaction message to the shard.

- The shard calls its ShardCommitCoordinator to add the cohort and
modificaton to a cached keyed by transaction ID.

- On CanCommitTransaction message, the ShardCommitCoordinator looks up and removes
the cohort entry from the cache corresponding to the transaction ID
passed via the CanCommit message. The ShardCommitCoordinator also caches
the cohort entry for the current transaction in progress. If there's no
transaction in progress, the committing transaction becomes the current
transaction and canCommit is called on the cohort. Otherwise, the cohort
entry is queued to be processed after the current tranaction completes.

- On CommitTransaction message, if the transaction ID passed via the
Commit message matches the currently cached cohort entry, the preCommit
and commit phases are performed. When complete, the ShardCommitCoordinator
dequeues the next waiting transaction cohort entry, if any, and process
it.

If a Tx is aborted and it is the current transaction, the
ShardCommitCoordinator handles it as a completed Tx.

Implemented a timeout mechanism using the akka scheduler such that if
the commit message isn't received after a period of time (default 30 s)
after the canCommit message, the transaction is aborted so that the next
transaction can proceed. This is to handle remote node or network
failures during a 3-phrase commit.

The ThreePhaseCommitCohort actor was removed along with the
ForwardedCommitTransaction.

Change-Id: Iaa5692ca45cd7635d1a06a609f4bf98bec50df14
Signed-off-by: tpantelis <tpanteli@brocade.com>