A tool for dumping the content of a store.

Very useful when debugging.
Fixed race during HA slaves creation
Merge pull request #2877 from thobe/1.9-dump-store

[1.9] A tool for dumping the content of a store
Merge pull request #2899 from lutovich/1.9-too-many-slave-client-threads

Fixed race during HA slaves creation
Fixed wrong consistency check error for deleted property
Merge pull request #2906 from lutovich/1.9-consistency-checker-too-picky

Fixed wrong consistency check error for deleted property
AutoConfigurator more resilient to unknown physmem

1. Makes figuring out the physicalMemory in the AutoConfigurator more
   resilient to ClassLoader restrictions that would prevent loading the
   interface that has the getTotalPhysicalMemorySize method.
2. Makes AutoConfigurator handle being unable to detect the physical
   memory behave in a better way, by still trusting the heap size and
   not treating it as if the heap has been configured too large.
Merge pull request #2910 from thobe/1.9-auto-config-physmem

[1.9] Make AutoConfigurator more resilient to unknown physical memory size
Merge '1.9-maint' into '2.0-maint'

Conflicts:
	community/kernel/src/main/java/org/neo4j/kernel/AutoConfigurator.java
	community/kernel/src/main/java/org/neo4j/kernel/impl/nioneo/store/StoreFactory.java
Needed update for 2.0:
	community/kernel/src/main/java/org/neo4j/kernel/impl/nioneo/store/DumpStore.java
	enterprise/consistency-check/src/test/java/org/neo4j/consistency/checking/PropertyRecordCheckTest.java
Merge pull request #2914 from thobe/2.0-merge-1.9

2.0<-[:merge]-1.9
New -host and -port args, some IPv6 support
Reenable test and possibly make it less flaky.
Merge pull request #2920 from lutovich/2.0-improve-backup-tool-args

New -host and -port args, some IPv6 support
Merge pull request #2923 from davidegrohmann/1.9-reenable-test

Reenable test and possibly make it less flaky
Merge remote-tracking branch 'upstream/1.9-maint' into 2.0-maint
Merge pull request #2936 from davidegrohmann/merge-1.9-into-2.0

Merge 1.9 into 2.0
Test case for race with commit updating the cache.

When a transaction commits, it will update nodes in the (object) cache
to add relationships to them that were created by the transaction. It is
however possible that the node was not in cache when the transaction
started its commit process, but was put into the cache by another thread
reading the relationships of that node. If this other thread read the
relationships after the committing transaction had written them to the
store, but before it updated the cache, the reading thread would have
already read the relationships that the committing transaction is about
to add into the cache. If that happens, the committing transaction will
still add these relationships, but now they will be in the cache twice
for that node.
Fix for race with commit updating the cache.

Extends the range of the locks acquired while writing to the store, to a
greater region including the place where we update the cache. Also make
sure we acquire corresponding read locks when attempting to read
relationships into the cache for a node.

This should be deadlock free because reader threads only ever acquire
a lock for one node at a time, and release it immediately after updating
that node. And while the writer thread acquires multiple locks, we only
ever have one writer thread acquiring locks at any given time.