Update deprecation warnings for server components
Added rewriting of 19 logs during update to 21
Minor code style fixes in test
A tool for dumping the content of a store.

Very useful when debugging.
Merge pull request #2886 from lutovich/2.1-migration-issue-of-19-logs

2.1 migration issue of 1.9 logs
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
Fixed race in CommitPusher, minor refactoring
Merge pull request #2899 from lutovich/1.9-too-many-slave-client-threads

Fixed race during HA slaves creation
Merge pull request #2900 from lutovich/2.0-race-in-commit-pusher

Fixed race in CommitPusher, minor refactoring
Fix possible test flakyness
More store upgrade integration test
Fixed wrong consistency check error for deleted property
Merge pull request #2883 from cleishm/deprecation-updates

Update deprecation warnings for server components
Merge pull request #2906 from lutovich/1.9-consistency-checker-too-picky

Fixed wrong consistency check error for deleted property
Evict DenseNode when deleting all rels of one type

When a relationship is deleted it needs to be removed from the cache for
the nodes it relates. This is done simply by evicting those nodes from
the cache. In earlier versions the log did not contain any information
about what those nodes were. So instead we based the eviction on the
fact that other, related, records would have changed when a relationship
was deleted, and based eviction on changed records instead.

For dense nodes, when deleting the last relationship of one type, the
records that change are the RelationshipGroup records, Relationship
records are only deleted, and no NodeRecord is (necessarily) updated.
This means that there is no updated record that will cause such an
eviction.

This is only a problem in HA, when we base these actions on records read
from the log. In standalone mode, even deleted relationship records
contain references to the nodes, since they were read from the store
before being put into the transaction state (in memory). When we write
to the log we omit such information, since all we (traditionally) care
about is the record being deleted.

Since the log contains the before-state of records as well as the after-
state, we can now evict nodes based on the before-state. This allows us
to perform eviction based on the very deleted records rather than the
rippling changes it causes. This cleaner eviction policy is what is
implemented in this change set.
Merge pull request #2904 from davidegrohmann/2.1-fix-test-flakyness

Fix possible test flakyness
Merge pull request #2905 from davidegrohmann/2.1-store-upgrade-test

More store upgrade integration test
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