MODE-1804 - Corrected the schema and the Hibernate Search parameters for the jgroups-slave backend.
MODE-1813 - Implemeted an Arquillian based test using CDI and various deployment units.
MODE-1816 REST v2 responses base property representations on number of values

The response should base the field value for a given property based upon
whether that JCR property is single-valued or multi-valued, not upon
the number of values. If multi-valued, then the field value should be
an array (even if there is just one item). Version 1 of the REST API
already works this way, but the version 2 was changed.

Note that it is still possible for property representations in
requests to use a single value (rather than an array) when setting
a multi-value to a single value, or the more conventional practice
of using an array to set a multi-valued array. The latter is obviously
required when setting the mutli-valued property to 0 or 2+ values.

Several of the expected results were incorrect and have been changed.
MODE-1809 Corrected the processing of set queries, including unions

The code was sorting and then removing duplicates in the tuples,
but during pre-processing and planning, the internal structure of the
tuples changed for certain kinds of queries (like unions with join)
to add in node location information as additional columns. The
removal of duplicates, however, was still incorrectly basing its
access of the tuple values upon the smaller/earlier tuple structure.
This cause various kinds of ClassCastExceptions.

Added a test case that replicated the originally reported problem,
which after the fix now passes.
MODE-1817 Corrected logic of concurrent removals

Added a relatively-simple test case that replicated the exact exception
using my hypothesized scenario. The test creates separate threads to
concurrently remove a specific node and (after synchronizing on a
CyclicBarrier) save their changes. Thus, the transient state of each
Session does not see the uncommitted transient state of the other
Session, but both sessions are saved roughly the same time (in different
threads so different transactions are used). But since both need to
acquire the lock on the same parent node, only one session will proceed
first to successfully remove the node. When the second session proceeds,
it no accepts the fact that the node was already removed and proceeds
accordingly.

(ACID transactions FTW!)

The fix was pretty simple: be aware that attempting to remove an entry
in the cache may return null if the entry does not exist (i.e., was
recently removed).
MODE-1796 Changed the InfinispanBinaryStore garbage collection logic

The RemoteCache or a RemoteCacheStore do not support map-reduce,
so we have to process the contents in a different way.