Committing Pom versions for Release 1.8.M05
Errors in the server, which are not errors from the actual request target,
i.e. errors such as protocol/comunication errors or bugs in the handling
code will write a proper failure response back to the client.
Committing Pom versions for 1.8-SNAPSHOT
Merge pull request #54 from tinwelint/failure-response-fix

Fix for o.n.com.Server error not sending back proper failure response
Tries to push out transactions to a configurable number of slaves
for each transaction either committed to master or on a slave.
Pushing the transactions out will take place after committed at
the master, but before tx.finish() returns.

Also renamed some occurences of master/slave classes and methods
so that the 'com' component has a generic naming, since now there's
a SlaveServer/SlaveClient implementation for master communicating
with the slaves too.
Updated changelog.
Includes server id in startup log message
Merge pull request #55 from tinwelint/less-branched-data

Tries to push out transactions to a configurable number of slaves
Fix for a 'flush last transaction' problem where a latency in ZK could result in master election never completing
Provides the ability to do rolling upgrades

- Extracts the Client as an interface.
- Provides two implementations for that, one from 1.5.3 and one from 1.8
- Adds a hook for being notified about mismatching versions in Client
- MasterClient instantiation now happens through a factory which is used in AbstractZooKeeperManager
- Adds a MasterClientResolver which is a MasterClientFactory that responds to MismatchingVersions from Client and instantiates the proper MasterClient version

The above deal with the communication protocol change from version 2 to version 3 in an automatic way.

- Adds the concept of a compatibility node in ZooKeeper. That is used to determine if we are in a mixed cluster or not and if we should go into compatibility mode.
- Refactors the tx id update code in ZooClient to inner classes so no more if() checks are necessary. One of them implements the compatibility mode.

The above provide automatic discovery of the new zookeeper master election algo and allow for a cluster to elect new masters only from old instances while an upgrade is in progress.
Revert "Provides the ability to do rolling upgrades"

This reverts commit ae5f7df4539c94eb441f82f2529d5c935b21acb9.
Revert "Revert "Provides the ability to do rolling upgrades""

This reverts commit 2b8f85073c8a87e75f9e4ab5a966e5bfff260cf0.
Better named threads
Adds documentation entry for the cluster upgrade procedure
Version reference changes and some manual formatting

Changes references to 1.5.3 as the previous version and replaces with generic "old" version
Removes styling as bash commands since it does not format well
Overrides correct getWriteLock/getReadLock method in SlaveLockManager
Fixed a concurrent modification bug
Changed synchronization regarding pushing transactions when slave committs a transaction to avoid deadlock scenario
Bumps the HA application protocol version

Since the new RPC call "push transactions" was added, the need to increase the application protocol arises. This commit does that and also introduces a compatibility layer for 1.6 and 1.7 clusters.
Updates HA changelogs