Remove duplicate properties during store migration from 2.1 to 2.2

Signed-off-by: Jakub Wieczorek <jakub@jakub.cc>
More complicated test data for the duplicate property removal on store migration
Further progress on simplifying the duplicate property fix-up in 2.1-2.2 migration
Addressing minor nits
Add a test for the NodeStore#scanRecords() method
Richer information to indicate the place where swith-to-slave even is cancelled.
Fixes for failing tests caused by the property deduplication during migration.
Add some sanity checking assertions to the property deduplication.
Merge pull request #3442 from S124568/2.1-null-uri-msg-in-cluster

Richer information to indicate the place where swith-to-slave even is ca...
Merge branch '2.1-maint'

Conflicts:
	enterprise/ha/src/main/java/org/neo4j/kernel/ha/cluster/HighAvailabilityModeSwitcher.java
	enterprise/ha/src/main/java/org/neo4j/kernel/ha/cluster/SwitchToSlave.java
Address a number of low-risk review comments on the property deduplication.
Merge pull request #3500 from digitalstain/master

Merge branch 2.1-maint into master
Fixes off-by-one error in DumpStore

- using try-with-resources when possible
Merge pull request #3477 from chrisvest/2.2-dupprop-migrate

Remove duplicate properties during store migration from 2.1 to 2.2
Fix inconsistent counts

Counts were becoming inconsistent when deleting a node and its
relationships in the same transaction. This is fixed by inspecting
the (pre-state) labels and relationships of the node that is being
deleted when building the counts from the transaction state.

Counts also became inconsistent during recovery, since commands in
the log did not contain information about the relationship type for
deleted relationships. We need this information in order to be able
to consistently update the counts, since we cannot trust what is in
the store during recovery. This is fixed by adding type information
to removed relationship commands in the log.

Recovery of the counts store also has a problem in that the counts
store did not have a marking to signal that it is inconsistent, since
it was updated in place. To mark the store as inconsistent / incomplete
the file is truncated before writing of the store is started.
Reading of a truncated file will show up as an IOException in
openVerifiedCountsStore(), this is handled in the same way as the
previous internal-consistency-check (which is still in place, and
complements this new additional check) of making sure that the number
of expected data entries written in the header matches the actual
number of data entries in the store.
The truncation is required since we would otherwise not be able to
recognize a partial write of the store where the new number of
records is the same as the old number of records.