rethinking ISPN transactions

Umbrella JIRA for several transaction related improvements:
1. Async options for commit/rollback (DONE)

• they don't really make sense as a user you don't get any guarantee on the status of the transaction
• they complicate the code significantly
• I think they should be removed

2. READ_COMMITTED

• it has the same performance as REPEATABLE_READ, but offers less guarantees.
• unlike REPEATABLE_READ, it also behaves inconsistently when the data is owned by transaction originator
• I think it should be removed

3. Optimistic tx without Write Skew Check (WSC)

• well, without WSC the transactions are not optimistic by definition
• they are something else: an batch update of multiple key/values. If the batch is successful you know the update was atomic. If it failed you don't get any guarantee
• suggestion: optimistic tx should always have WSC enabled (no option to configure it)
• build our batching functionality on top of what currently is optimistic tx without WSC and document it as such

4. Remove 1PC option

• I'm not totally sure about it, but does it really make sense to have 1PC as an option? they don't offer any consistency guarantees so async API + non tx do about the same thing

5. Configuration changes

• remove (deprecate first) write-skew attribute. it will be enabled automatically when needed to keep the data consistent
• remove eager-locking-single-node. deprecated since 5.1 (DONE)
• remove transaction-protocol and add TOTAL_ORDER to locking-mode. Since total order is an alternative, it makes more sense to be in the locking mode than in the separate attributed.
• remove eager-locking. deprecated since 5.1 (DONE)
• move isolation-level to <transaction>. it only makes sense for transactional caches.
• remove single-phase-auto-commit ?? it is 1PC for auto-commit transactions. does it make sense to have it? it doesn't provide any guarantees.

6. Internal changes

• remove list of WriteCommand and keep a map between key and new-value, new-metadata and version-read. A null value means a remove operation.

7. Create a single XaResource/Synchronization per cache-manager instead of per cache.

8. For implicit transaction and auto-commit=true, if the transaction fails to commit, it can be retried until succeed. This will make the conditional operation to return a valid return value. Possible problem with retry is when a partition happens and it may fail the transaction forever.

• note: conditional operations that return true or false doesn't need to retry the transaction. They can return false when the transaction fails.

[1] http://markmail.org/thread/a7fjko4dyejxqgdy
[2] https://github.com/infinispan/infinispan/pull/2177
[3] http://infinispan.markmail.org/thread/nl2bs7rjvayjcybv
[4] http://infinispan.markmail.org/thread/vbg6g4otu7djazbc