CDS: Changes to Tx abort in Shard

CDS: Changes to Tx abort in Shard

I noticed when a tx times out on the front-end during CAN_COMMIT, it
tries to abort the tx but it may not get aborted in the Shard and the
front-end gets an AskTimeoutEx on the abort. The reason is that the
Shard only processes the abort request if the tx is the current tx being
committed. If it isn't, the request is ignored and no response is sent,
resulting in the front-end timeout.

I think it makes sense to also process the abort if the tx is sitting in
the queue awaiting CAN_COMMIT. If the front-end says to abort for any
reason, the Shard should honor it. Also, if it isn't aborted, the Shard
may dequeue it sometime later and attempt to commit it which can lead to
unpredictable results if prior commits failed.

As per the comments in the Helium patch, I did some re-factoring to make
it a bit cleaner. I moved the abort code from the Shard to the
ShardCommitCoordinator. This makes it consistent with the other tx
phases where the Shard mostly delegates to the ShardCommitCoordinator. I
also removed the getCohort method from CohortEntry and added appropriate
methods so the internal cohort instance isn't exposed.

There's more refactoring/cleanup that can be done re: Futures and also
moving CohortEntry into its own class (it's large enough) but I don't
want to overload this patch.

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