Always start with a clean test directory.

o We previously had tests cleaning out their test directory or not
  seemingly at random. In most cases it's fine to start with a clean
  directory, which simplifies things.

o We have a few cases which genuninely need to get hold of the test
  directory without cleaning it out. Most of these are part-way through
  a test where we need to start a database running against an existing
  store.

o The interface of TestDirectory has been changed to get rid of boolean
  flags and have intention-revealling method names instead.
Fix for exhausting the Neo4j Server ThreadPool with too many selectors, so that no acceptors are available

* extracted HttpConnectorFactory
* SslConnectorFactory inherits from it to use the same approach
* Jetty makes wrong choices for selectors (numcpu instead of numcpu/2), so we have to provide explicit counts for selectors and acceptors
* Determine number of relevant CPUs by taking the size of the thread pool into account
* Add some other performance related configurations from the Jetty docs
Don't delete test directories after successful tests.

We have tests that are flaky because of failures to delete files on
Windows. This is caused by a problem with Windows/Java where files that
have been memory-mapped have locks held longer than expected (see
http://bugs.java.com/bugdatabase/view_bug.do?bug_id=4715154). We can
work around this problem completely by not even trying to delete the
test directories.

This means that subsequent runs of the tests will start with dirty
directories. There is an earlier commit which changes all our tests to
clean out the directories that they use before they start running the
tests.
Merge pull request #2199 from jexp/server-threadpool

Fix for exhausting the Neo4j Server ThreadPool with too many selectors, so that no acceptors are available
Fix memory leak in XaResourceManager.

The txOrderMap was initially only meant for and used by recovery. However, HA started
injecting transactions using the same recovery code as well. This meant that the
txOrderMap was steadily accumulating data, but never got cleared, because the clearing
only happened at the end of recovery.

This memory leak has been fixed by removing the txOrderMap completely, and instead let
the TransactionStatus objects know how to order themselves.

Conflicts:
	community/kernel/src/main/java/org/neo4j/kernel/impl/transaction/xaframework/XaResourceManager.java
	community/kernel/src/test/java/org/neo4j/kernel/impl/transaction/xaframework/TestApplyTransactions.java
Lazy properties now use a provider for PropertyStore.

- Fixes a cache issue where LazyProperties would hold old reference to
  property stores after a data source restart.
Merge pull request #2212 from cleishm/cherry-xa-leak

Cherry-pick from 1.9-maint: Fix memory leak in XaResourceManager.
Merge pull request #2209 from benbc/2.0-always-start-with-a-clean-test-directory

Always start with a clean test directory.
Merge pull request #2210 from benbc/2.0-dont-delete-test-directories

2.0 dont delete test directories
Merge pull request #2213 from jakewins/2.0-lazyprop

Lazy properties now use a provider for PropertyStore.
Removes an unnecessary debug log statement
Make UDC user agent recording more testable.

o We have been getting sporadic failures of the UDC
  CollectUserAgentFilter integration test. It looked like this was
  because 1) we were testing the logic through an integration test and
  2) the logic was complicated because of the sampling that was being
  done (only recording one in a hundred requests).

o I have added a unit test to cover most of the logic.

o I have removed the sampling so that we now record every request. The
  sampling was originally put in to reduce possible performance impacts
  of the filter. I have changed the implementation so that it no longer
  uses regular expressions (String#split() has a special case for
  single-char delimeters) and read the Jersey code that we call to get
  hold of the request headers; I'm convinced that everything that we do
  now is very fast, so the sampling is not necessary.

o In order to make the whole thing more testable (to avoid problems with
  static state), I have re-worked the way the state is stored. It's
  somewhat convoluted to satisfy the various constraints that are put on
  us by the way this code is used. See CollectUserAgentFilter for
  details.

o Because the interface of CollectUserAgentFilter has changed, we need
  to rework the UDC integration testing. This integration testing is
  somewhat tricky because of the way our Maven modules are stiched
  together. Previously we had a dummy implementation of the filter for
  UDC testing, but that meant that it's easy for the interface to get
  out of sync. Instead I've moved the integration testing into its own
  project so that it can depend on both server and UDC without
  introducing a circular dependency.
Improved TopPipe performance by 600x

* made Expression.isDeterministic a val
* use a tuple with extracted context values for sorting, remove the need to re-lookup each expression value
* implement proper top-n select using a "runtime" approach with Arrays and binarySearch
Merge pull request #2230 from jexp/top-pipe-performance

Improved TopPipe performance by 600x
Validate docbook xml using mvn.
Build manpages using mvn.
Remove manpages in text format.