Fix UniqueConstraintStressIT: Catch expected exception: Constraint violation on slave.

The constraint added by the master transaction will eventually get pulled by the slave
and a constraint violation due to a slave will be caught during the transaction building
phase instead of the commit phase, resulting in different end user exceptions.

A test case variation making this case more likely was added.
Refactoring of record positions in NeoStore
Documentation fixes, mostly for embedded.

* Refresh of embedded usgae docs for 2.2.
* Small tweaks to Cypher docs.
* Increasing wait time for indexes in neo4j-graphgist.
* Minor cleanup in docs for tx endpoint.
* Minor cleanup in docs for neo4j-import.
Fix a bug in the counts store which prevents recovery to happen

The CountsTracker code was checking that the txId stored in the Counts
Store is never smaller than the txId stored in the NeoStore.  This is
not always true. The wrong assumption here is that dispite the fact
that the code rotates the Counts Store before flushing the NeoStore
pages, it might happen that the PageCache decides to evict the
NeoStore pages (and hence flush them to disk) before the Counts Store
rotation. The fix is basically removing the check and trust recovery
to fix the stores.
Fix an NPE during startup when dump_configuration is enabled
Errors in Bootstrapper.start are logged to System.out if logging failed to initialize
Merge pull request #3633 from nawroth/2.2-docs-fixes

Documentation fixes, mostly for embedded.
Merge pull request #3632 from martinfurmanski/2.2-unique-constraint-stress-it-slave-constraint-case

Fix UniqueConstraintStressIT: Catch expected exception: Constraint violation on slave.
Merge pull request #3636 from davidegrohmann/2.2-counts-store-fix

Fix a bug in the counts store that prevented recovery from happening
Merge pull request #3638 from chrisvest/2.2-pagecache-npe

Fix an NPE during startup when dump_configuration is enabled
Merge pull request #3634 from lutovich/2.1-npe-in-bootstrapper-catch-block

Null-safe logging in Bootstrapper
Merge '2.1-maint' un 'master'

Conflicts:
	community/server/src/main/java/org/neo4j/server/Bootstrapper.java
Stores checksum of last transaction in neostore record

This means that there is no longer a need for having a "last transaction"
in a transaction log for the sole purpose of extracting a checksum from
its start entry. This simplifies usages around backup and HA.

This commit also changes the HA protocol, the handshake specifically,
where previously the handshake contained a checksum and a masterId for
that transaction. That wasn't necessary to have since that masterId value
was and is already part of the checksum.
Unknown relationship types in a dense node should not cause relationship loading
(cherry picked from commit 5116cd0)
Fixed a collision handling issue in IdMapper

where encoded values where compared before clearing an internal collision
flag on each value. Better testing was added around collision handling to
assert correct behaviour there as well.
Merge pull request #3631 from tinwelint/2.2-no-need-last-tx

Stores checksum of last transaction in neostore record
Reduce the probability of false dead-locks on index entries

Our locking API works on tuples of a ResourceType and an opaque resource id, represented as a 64 bit long.
This works great for node and relationships, as the resource id is just the record id.
Schema index entries, however, are actually tuples of label, property key and the indexed value.
Therefore, when we take a lock on an index entry, we produce a hash of the index entry tuple and take a lock on the hashed value.
It turns out that the hash function we previously used for these index entries, was quite prone to producing collisions.
Especially amongst values that are close to each other in an ordered sequence.
In the test I've added here, I saw a collision ratio of about 10%.
The new hash function is much more robust, and shows a 0% collision ratio, which only makes sense since we're dealing with a mere 25 million entries.
A sample set size that is practically microscopic compared to the space that is available to us in 64 bits.
If the 64 bit state space was all the sand in Sahara, our test would have looked at 2.5 million tons of sand (not as informative as I would have liked, but I had fun calculating it).