Fixed argument handling in optional match
Reintroduce tracking of active transactions on master side

to fix an issue where locks could get stuck. The problem was that a
rollback on the slave due to lock timeout would go over to the master and
end the lock session too early, before the last acquiring thread might
have finished its waiting. So when the pending lock acquisition would
complete the lock would be registered and then never released since the
lock client had already been closed.

With this commit, when the slave rolls back, the lock session on the master will be
closed if there is no thread awaiting a lock acquisition. If there is a
thread awaiting a lock acquisition the session will just be marked as
"please finish asap" and the session reaper will close it as soon as the
lock acquisition has completed.

This exact behaviour existed in 2.1 and in previous versions, but was
removed by mistake in 2.2 due to suboptimal understanding of the scenario
described above.
Created a filter for dealing with X-Forwarded-Host and X-Forwarded-Proto much further down the stack than they currently are. This should enable all of the Neo4j server resources (including / and /db/manage) to be addressed via an external hostname and other URI scheme.
Created a filter for dealing with X-Forwarded-Host and X-Forwarded-Proto. Moved the handler code out of the OutputFormatProvider into a jetty filter much further down the stack. This should enable all of the Neo4j server resources (including / and /db/manage) to be addressed via an external hostname and other URI scheme.
Tidied up unused variables.
Made sure the regex can deal with transaction IDs greater than 9 to rectify a flaky test (which actually fails locally for me)
Adding neo4j license headers to fix the build
Merge pull request #2888 from tinwelint/2.2-lock-stuck-issue

Reintroduce tracking of active transactions on master side
Merge pull request #2894 from pontusmelke/argumentids-optional-match

Fixed argument handling in optional match
Add tests about cluster startup

- master/slaves should always join a cluster when the database directory is empty
- slaves should always join a cluster when the database directory contains the store
  files but no logical log files
- a database directory with store files but no logical log files can be used
  to seed a cluster