MODE-2036: Add permissions testing inside Node's methods
MODE-2034 Fixed the restore operation of a parent with 2 unversioned children. The underlying problem was caused by the fact that when performing "orderBefore" operations, children appear both as removed and insertedBefore. However, the existing child reference iterators were always seeing the nodes as removed.
MODE-2028 Updated the EAP kit to 6.1.1.GA
MODE-2039 Fixed the import of documents which have the "isCheckedOut" flag set to "false".
MODE-2042: Test permissions for principals known to the security context
MODE-2042: Optimized permissions checks. Added Testcase
MODE-2035 Fixed the mode:lock node type which caused the reported problem. Also, this exposed another problem with the XmlNameEncoder - the fact that XML names cannot start with certain characters.
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.