Add support for reading 2.1 log files
Such a feature is needed to upgrade from 2.1 to 2.2 when using HA
Add a test case for upgrading from 2.1 to 2.2 in all scenarios: embedded, server, and HA
Various cleanups and small improvements
Add support for upgrading from 2.1 store

- bumped store version for 2.2 to 0.A.4
- introduce tests for upgrading from each older version: 1.9, 2.0, and 2.1
- cleanups and improvements
Revert "Updated PID file location to come from configuration"
Merge pull request #2928 from neo4j/revert-2827-master

Revert "Updated PID file location to come from configuration"
Merge pull request #2893 from davidegrohmann/2.2-read-2.1-logs

Support for reading 2.1 log files and upgrading from 2.1 store files
Transactions are forced in batches to the log

During the commit process of a transaction the changes to be made are
first written to a log. Those changes has to be forced to disk before
starting to make any changes to the store. Forcing bytes to disk can be a
big bottle-neck.

To keep the contract of forcing before making store changes, but yet
be performant this commit introduces batching for the part that does the
forcing of the log down to disk. The committer appends its changes to the
log and then instead of forcing there and then grabs a ticket (basically a
sequential id) from a separate thread forcing the log as often as it can
while there are changes to force. The committer then goes and waits for
the next ticket to be completed, which signals that its changes has been
forced. The more threads that commits concurrently, the greater the
benefit.

This is from now on going to be the default behaviour, but can be turned
off with configuration setting 'batched_writes=false'.
Closing of transactions in presence of failure to append

this to help the shutdown process which blocks until all transactions are
closed. In the event of failure to append to log, where the failure
happens after a new transaction id has been generated, then that
transaction id isn't returned from the append method since it throws
exception. The id is kept with the transaction so that the caller can
close the transaction, just as a successful append+apply would do.

This is what the commit process does when receiving such exceptions and
also issues a kernel panic, of course.