MODE-2031 Fixed the updating of modified node types on repository start. The problem consisted in the fact that after the update, super-types were placed after regular types in the list of children of the jcr:system/jcr:nodeTypes node and therefore couldn't be found during node type validation.
MODE-2042: Optimized permissions checks. Added Testcase
MODE-2045: Fix for failed tests
Corrected compiler warnings
MODE-2043 Mechanism for programmatic steps during upgrades

When ModeShapde code is upgraded, sometimes it is necessary to also
upgrade stored content. For example, an upgrade might change a built-in
node type and change the code that uses it, but the software cannot
change any persisted nodes that use that old node type to reflect the
new state. There are of course other examples.

This commit adds a new small system for performing upgrades. Each time
a repository is started up, internal repository state is examined to
learn which (if any) of the known upgrade steps (operations) need to
be applied. If any are needed, those steps are applied and the repository
state changed to reflect this. This is done efficiently (since most
starts are done with the same software version) and in such a way
that only one process in a cluster (the first to recognize the
need to run upgrade steps) will perform such steps while additional
processes wait (for a maximum of 10 minutes) until the first process
completes the upgrade.

Internal inner classes are used to implement each upgrade steps, and
upgrade steps are identified by a simple integer identifier. The steps
are intended to be sequential applied, and thus a monotonically
increasing integer ID is used. This highest ID of the upgrade step
last applied to the repository is stored inside the repository
state. If a new upgrade step is needed for a release, a new inner
class is added and the existing ones kept as-is. This makes it easy
to apply all of the upgrade steps needed to bring the repository
content from being compatible with an earlier release to a state that
is compatible with the most recent release. This ID mechanism is simple
and completely independent of version numbers.

It is also very easy and quick to determine upon repository startup
whether any upgrade steps need be performed. Most of the time the
software version does not change and the repository's last-applied
upgrade ID matches the highest upgrade step known to that software.
Thus, a simple integer comparison is all that is required to completely
bypass the upgrade process in clustered and non-clustered topologies.

Note that all newly-created repositories are pre-initialized with
the highest available upgrade step ID, so that no upgrade operation
never needs to be performed on a new repository.
MODE-2045: Fix for failed tests
MODE-1467 Added ability to explicitly invoke sequencer within session

ModeShape now supports applications explicitly invoking sequencing
from within the scope of a session. There are several differences with
using sequencers in this style:

- A specific sequencer must be named, and only that sequencer will be
invoked.
- The path expressions of that configured sequencer are not used in
any way. All other configured properties are still used.
- The sequencer's accepted MIME types are still respected. If the
input content's MIME type is known and is not in the sequencer's set
of supported MIME types, the sequencing operation will return immediately.
- The caller must supply the property containing the value to be
sequenced.
- The caller must supply a new node into which the sequencer output
will be placed.
- The session used to sequence contains all sequencing output as
transient state; the caller is expected to call 'session.save()' if
the output is to be persisted.
MODE-1875 Enabled delta-based cluster replication after validating it with ISPN 5.2.7.Final and JGroups 3.2.10.Final. Also, fixed the standalone-ha and domain xml clustering configurations.
MODE-2024 Changed RepositoryChangeBus to use queue.take() instead of poll() and simplified internal thread creation so that fewer threads are spawned.
MODE-2043 Added some tests for the upgrade mechanism and a small code refactoring.
Corrected JavaDoc errors
MODE-2044 Implemented the upgrade function for the 3.6.0 release.
MODE-2047 Fixed locking of transient nodes. According to the Javadoc from the spec methods any kind of locking on node which contains modifications should throw an InvalidItemStateException.
MODE-2029 Added test case to verify the behavior reported in the issue.
MODE-2032 Changed the order of searching for log factories and added more information about which logging library is used.
MODE-2050 Fixed NoClientTransactions to hold the active transaction on a per-thread basis.
MODE-2049 Fixed repository shutdown when monitoring is not enabled
MODE-2051 Added a series of different tests around storing binary values in ISPN, including tests for validating clustered binaries.
MODE-2053 Fixed NPE caused by missing method implementation in SelectComponent.
MODE-2055 Fixed session.getNodeByIdentifier to not return the version history node.