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
Merge pull request #1599 from tinwelint/1.9-the-two-commits--a-cherry-pick-story

Two HA commits cherry picked from master