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
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
Merge pull request #1880 from digitalstain/phase2timeoutRetryFix

Fixes an issue with phase2Timeout on proposer state
Merge remote-tracking branch 'upstream/master' into 1.9-merge
Merge pull request #1885 from digitalstain/1.9-merge

1.9 merge
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.
Fixed a conflict resolution mistake

effectively removing an (almost) duplicated line. Introduced by
46c41198a17b94f352cbe4e4e8c62778c442c172
Doesn't close IndexReader after verifying deferred constraints

that should be up to the SearcherManager. Closing the IndexReader manually
and then trying to release the searcher holding will fail and consecutive
calls to SearcherManager#acquire will get stuck in busy-loop.

This solves a problem that caused the index population phase to hang after
the node scan was complete, when flipping to ONLINE state and there were
one or more updates to apply before flipping. Having a constraint creation
hang caused the schema write lock be held indefinitely.
Merge pull request #1886 from tinwelint/2.0-fix-constraint-hanging

Discussed with @tinwelint. I had misunderstood the lucene APIs and this change looks sensible.
Updates changelogs for 1.9.6
CHANGES.txt for indexing changes.
Updates changelogs for 2.0.1
Merge pull request #1887 from apcj/2.0-changelogs

2.0.1 changelogs
Makes field final in PaxosClusterMemberEvents.ClusterMemberSnapshot

Also fixes some formatting in PCME
Fixes cluster joining process for Ha backup clients

There were two problems with HaBackupProvider, both on cluster
 joining. One was that it depended on snapshots to discover the
 state of the cluster, while since 1.9.6 this has changed and joining
 instances must as for elections. The other was that it passed in a null
 for a SnapshotFilter, which caused NPEs and did not let the availability
 messages to be processed. Both problems are now solved.
Changes ignore reason for BackupHaIT test

Before it was a pending backport. Unfortunately, there appears to be
 some flakyness in the test, which points to a bug. Needs investigation.