fixes neo4j/neo4j#1855

guarantee initialization order of supplied unmanaged extensions by using java.util.List instead of java.util.Set.
Removes the ComException wrapping of server-side BranchedDataException

which is no longer needed due to recent changes in exception streaming
from server to client. In fact the wrapping prevented a slave to properly
react to branched data and would make that slave unable to ever join the
cluster.
Making the reporting of BiasedWinnerStrategy a bit easier to

o This is a 1.9 version - lots of classes moved around so I've
  submitted a 2.0 version as well
o Changed wording so it describes it in words that will be easier
for the field team to understand
o Added tests around the BiasedWinnerStrategy
Merge pull request #1871 from mneedham/1.9-maint-bws

Making the reporting of BiasedWinnerStrategy a bit easier to
Merge pull request #1870 from tinwelint/1.9-branched-slave-fix

Removes the ComException wrapping of server-side BranchedDataException
fixing compile error in neo4j-desktop
Fixes an issue with phase2Timeout on proposer state

When an instance times out on phase 2, if it is closed or delivered
 it should have its payload retried. This patch adds this functionality.
Also fix false index collisions for online indexes

The story so far:

* Indexes store all numbers as doubles, and that means that large long values
  can coerce to the same double values and cause collisions in the index.
  We fixed this for indexes that are populating, by making them read colliding
  values out from the property store to double check if the collision is real
  or not.
* We also added a similar "exact match" filtering to the index lookup
  operations on StateHandlingStatementOperations, to fix index lookups.
* What we didn't fix in the first round, was adding new stuff to indexes that
  are online. This is the bug that Mattias found.
* Specifically, the UniquePropertyIndexUpdater verifies that the constraint is
  still holding in its close method.
* This is super bad, because the close method is called in commit - not in
  prepare, not during the transaction - in commit. Huge no-no.
* Initially you'd think that this puts recovery at risk, but that turns out not
  to be the case, because during recovery, we use a normal index updater
  instead of the unique one.
* So this means that the following scenario was possible: Add two nodes with
  similar but distinct long values to the index. The
  ConstraintEnforcingEntityOperations is fine with this because the values are
  really different. However, the UniquePropertyIndexUpdater trashes the
  transaction in commit. Now suppose the entire database server crashes for
  whatever reason, and we must do recovery. We recover the index using the
  normal updater that just adds the values without checking any constraints.
  And this is actually totally fine, because we filter for exact matches in the
  StateHandlingStatementOperations. And so only then does the index work as
  advertised. We had to crash the database in order to add a valid value to the
  index. Except, there is a window between the crash of the transaction, and
  the crash of the database, where the transaction could have been retried with
  the same exact value and encounter the same exact crash. Now we recover both
  transactions, and boom: we got a duplicate in the unique index!
* The solution I'm going for currently is to just not verify the constraint in
  the UniquePropertyIndexUpdater.close method... just accept the value as
  given, and trust that the ConstraintEnforcingEntityOperations has done it's
  job.
* Implementing this solution is made a bit harder by a number of tests
  operating directly with the IndexUpdaters, instead of checking the publicly
  observable behaviour.
* I intend to rephrase these tests in terms of higher level APIs, but in the
  mean time (because there are a lot of cases to cover) we will have to ignore
  all the now failing tests, and see what the robustness suite says.
Fixes #1876 - Null nodes and properties should be ignored when SETting properties
Logs file sizes when copying store files from master
Makes sure a literal map can't be used with the SET clause
Merge pull request #1881 from chrisvest/duplicate-number-index-fix

Also fix false index collisions for online indexes
Merge pull request #1882 from systay/1876

Fixes #1876
Removes LogBufferFactory and its default implementation

There was only one implementation of LogBufferFactory which
 was a straightforward call to DMLB constructor. This did
 not call for the need for a factory abstraction and since
 it was complicating upcoming work on monitoring it has now
 been removed.
Introduces byte count monitoring in DirectMappedLogBuffer

Uses the Monitors functionality to add bytes written counting
 facilities to DirectMappedLogBuffer. Achieved via introducing
 a LogBufferMonitor interface that is used by DMLB.
XaLogicalLog and TxLog require access to Monitors to
 create the proper monitor and pass it to their DMLB.
Renames LogBufferMonitor to ByteCounterMonitor

It is clear after some usage that log buffer monitoring is really
 a case of counting bytes, functionality that needs to be replicated in
 other places as well. It makes sense therefore to have LogBufferMonitor
 strictly count bytes, rename it to ByterCounterMonitor and reuse it
 where necessary.
Removes support for HA protocols from versions 1.5.3 and 1.7

Ha protocols from versions 1.5.3 and 1.7 are no longer supported for
 rolling upgrades. Hence they are no longer necessary to be present
 in the codebase.
Introduces usage of ByteCounterMonitor in XaLogicalLog operations

LogExtractor now updates a ByteCounterMonitor with bytes read while
 extracting transaction entries from a log
XaLogicalLog updates a ByterCounterMonitor when deserializing
 prepared transactions from disk for sending over the network
XaLogicalLog now updates a ByteCounterMonitor when deserializing
 a transaction stream over the network
Introduces monitoring in network HA operations

BlockLogBuffer now updates a ByterCounterMonitor with the bytes it
 writes to the underlying buffer. This way all operations that
 serialize transactions to the network can be monitored.
Master and Client instances now make use of that BlockLogBuffer
 for streaming results and transactions.
Introduces a RequestMonitor which logs HA requests. It supports
 request context via a hashmap which can be set to contain various
 information about the request logged.
Client and Server now update a RequestMonitor with requests sent
 and received, respectively.
Moves ByteCounterMonitor to o.n.k.monitoring package

ByteCounterMonitor is generic enough so it does not have to be
 in o.n.k.i.t.xaframework anymore