Refactored contexts for Paxos state machines to make it easier to test states.
Merge remote-tracking branch 'origin/1.9-maint' into 1.9-maint

Conflicts:
	enterprise/cluster/src/main/java/org/neo4j/cluster/protocol/cluster/ClusterContext.java
Merge remote-tracking branch 'origin/1.9-maint' into 1.9-maint
Merge issues fixed
Keeps explicit state whether a transaction is remotely initialize or not

instead of relying on lock information (whether any lock was grabbed or
not). There was a problem where the "old" transaction state was checked
for locks and not the new one (the one in the Kernel API), or preferrably
both should have been checked. But that approach was error prone so an
explicit flag is better and safer.

Also renamed TxHook --> RemoteTxHook because that name and its method
names were so misguiding that it slowed down reasoning around problems
where it was involved.

The fix in this commit is for a regression from 1.9, but may also fix some
other corner cases with remote transaction management.

Also had to pull in some constructs from
e5cdeec2b7706aefd1bb88cd62409a0591ca2f0f due to differences in data source
enlisting timing between 1.9 and 2.0.

(cherry picked from commit e9a88b91d0c59627a25f81d0b523ba44cea3890b)

Conflicts:
	community/kernel/src/main/java/org/neo4j/helpers/Exceptions.java
	community/kernel/src/main/java/org/neo4j/kernel/DefaultTxHook.java
	community/kernel/src/main/java/org/neo4j/kernel/InternalAbstractGraphDatabase.java
	community/kernel/src/main/java/org/neo4j/kernel/impl/core/NoTransactionState.java
	community/kernel/src/main/java/org/neo4j/kernel/impl/core/TransactionState.java
	community/kernel/src/main/java/org/neo4j/kernel/impl/core/WritableTransactionState.java
	community/kernel/src/main/java/org/neo4j/kernel/impl/nioneo/store/NeoStore.java
	community/kernel/src/main/java/org/neo4j/kernel/impl/transaction/TransactionStateFactory.java
	community/kernel/src/main/java/org/neo4j/kernel/impl/transaction/TxManager.java
	enterprise/ha/src/main/java/org/neo4j/kernel/ha/HighlyAvailableGraphDatabase.java
Prevents local slave lock acquisition waiting after granted on master

A slave in an HA cluster acquires locks by first acquiring it on its
master, and if granted go and acquire it locally. Given that the master is
the authorative instances w/ regards to locks in the cluster it is
expected that acquiring a lock that the master just granted should not
have to await any condition - it's expected to be free to acquire. However
that is apparently not the case since sometimes the slave comes back from
the master having just acquired it and it goes and blocks, awaiting the
lock to be free since some other transactions holds it presumably.

The problem described above in many cases results in such a lock being
stuck forever on the master, where the only way to release it would be to
restart that database.

This commit doesn't fix the issue that is the confusion that the master is
not the single authorative entity of locks. The fix here is to prevent a
local lock acquisition, after master acquired such, to go and wait for that
lock to be free locally. If that would happen then it will not wait, but
instead throw a DeadlockDetectedException (actually a subclass thereof)
containing diagnostics about which locks are present in the local lock
manager. These deadlock detected exceptions will walk and quack the same
way a "real" such deadlock and a normal retry of the transaction will put
things right again.

The root cause will have to be fixed, but having a few more deadlock
detected exceptions thrown to the client instead of leaving unreleasable
locks on the master behind is a massive improvement.

For reference, this issue caused many unexpected BlockingReadTimeoutExceptions
to be thrown, exceptions of which there should be much less of after this commit.

(cherry picked from commit 39be5a3a284c8be60cf058482863b7436d09351b)

Conflicts:
	community/kernel/src/main/java/org/neo4j/kernel/impl/transaction/LockManager.java
	community/kernel/src/main/java/org/neo4j/kernel/impl/transaction/LockManagerImpl.java
	community/kernel/src/main/java/org/neo4j/kernel/impl/transaction/RWLock.java
	enterprise/ha/src/main/java/org/neo4j/kernel/ha/com/master/MasterImpl.java
	enterprise/ha/src/main/java/org/neo4j/kernel/ha/lock/LockManagerModeSwitcher.java
	enterprise/ha/src/main/java/org/neo4j/kernel/ha/lock/SlaveLockManager.java
Adds 5 seconds to tx timeout on master, removing a thundering herd.
Fixes incorrect synchronization on switch to master

If an instance receives a masterIsAvailable for itself while recovering
 the database, bad things can happen. Adding synchronization on
 xaDataSourceManager solves this.

This is a backport of 870c0625139593d14abf131cad31fcab9c56ce5e
Merge pull request #1599 from tinwelint/1.9-the-two-commits--a-cherry-pick-story

Two HA commits cherry picked from master
Suspends the transaction in a finally block

since we must uphold the contract where the transaction must have been
suspended no matter what happens before leaving that method.

(cherry picked from commit c82701d2a0bddf39b77e795638bd98555fc46540)

Conflicts:
	community/kernel/src/main/java/org/neo4j/kernel/impl/transaction/TransactionImpl.java
	enterprise/ha/src/main/java/org/neo4j/kernel/ha/com/master/MasterImpl.java
Throws more specific exceptions from TxManager#resume

There are two possible failures that can happen in #resume:
 (1) The current thread has already got another transaction associated with it
 (2) The transaction to be resumed is already associated with another thread

These two failures got their own exceptions: ThreadAssociatedWithOtherTransactionException and
TransactionAlreadyActiveException so that callers can react appropriately
to the two scenarios. Typically there's special handling of (2). Doing
this made UnableToResumeTransactionException redundant, and it was too
generic to begin with as it represented both (1) and (2).

This commit also tidies up and corrects logging regarding old transactions
on the master which are to reaped, so less logging and more relevant
logging there.

(cherry picked from commit 5581112812f76e96bf9f683d13f323e997c09b0e)

Conflicts:
	community/kernel/src/main/java/org/neo4j/kernel/impl/transaction/TxManager.java
	enterprise/ha/src/main/java/org/neo4j/kernel/ha/MasterClient20.java
	enterprise/ha/src/main/java/org/neo4j/kernel/ha/cluster/DefaultMasterImplSPI.java
	enterprise/ha/src/main/java/org/neo4j/kernel/ha/com/master/MasterImpl.java
	enterprise/ha/src/main/java/org/neo4j/kernel/ha/com/master/MasterServer.java
Introduces a tiny sleep in the loop that checks HA availability

to avoid heavy CPU busy-wait
Removes the need for HA snapshots on cluster join

Slaves now will respond to masterIsAvailable events with slaveIsAvailable
 always. That means that when an instance joins, it will see all the
 availability events that make up the cluster, bringing it up to date.
 This removes the need for snapshot to be received on cluster join.

Conflicts:
	enterprise/ha/src/main/java/org/neo4j/kernel/ha/HighlyAvailableGraphDatabase.java
	enterprise/ha/src/main/java/org/neo4j/kernel/ha/cluster/HighAvailabilityModeSwitcher.java
Ignores TransactionNotPresentOnMasterExceptions

This was done already but not for all cases. Puts that catching in one
place so that all code paths benefit.

Conflicts:
	enterprise/com/src/main/java/org/neo4j/com/Server.java
Fixes issue where more HA availability messages than necessary were broadcast

Previous attempt in this area left open a bug where for example the master receiving
 a SlaveIsAvailable event would make it broadcast a MasterIsAvailable event again,
 refuelling a loop of such exchanges. This makes sure that the instance's state and
 the incoming transition are examined to decide on what to broadcast.
Introduces tests for the above.

Conflicts:
	enterprise/ha/src/test/java/org/neo4j/kernel/ha/cluster/HighAvailabilityModeSwitcherTest.java
Improved data provided by AvailabilityGuard to help debugging.

Conflicts:
	community/kernel/src/main/java/org/neo4j/helpers/collection/Iterables.java
	community/kernel/src/main/java/org/neo4j/kernel/AvailabilityGuard.java
	community/kernel/src/main/java/org/neo4j/kernel/InternalAbstractGraphDatabase.java
	community/kernel/src/test/java/org/neo4j/kernel/impl/transaction/TxManagerTest.java
	enterprise/ha/src/main/java/org/neo4j/kernel/ha/HighlyAvailableGraphDatabase.java
Improved logging for failure on rollback.

Conflicts:
	community/kernel/src/main/java/org/neo4j/kernel/impl/transaction/TxManager.java
Improved error reporting for file lock failures.
Fixed message reordering issue by using two stacks

Conflicts:
	community/server/src/main/java/org/neo4j/server/rest/batch/BatchOperations.java
Fixes message reordering issue in Atomic Broadcast

Messages that created new messages caused a message reordering
 issue that can really screw things up. This deals with that by
 replacing the single queue with two stacks that are cleverly
 bounced back and forth to get the correct ordering.
Adds a test for this condition

Authored by Rickard Oberg

Conflicts:
	enterprise/cluster/src/main/java/org/neo4j/cluster/StateMachines.java