MODE-1542 - Investigated and added test for uploading large binary values (files) via the WebDAV interface.
MODE-1637 - Fixed the stopping of the modeshape garbage collection cron thread when the engine shuts down
MODE-1638 - Added a check when removing workspace caches, to see if the ISPN cache manager has the status running
MODE-1613 - Added a unit test in attempt to reproduce the issue
MODE-1639, MODE-1640, MODE-1634 Replaced the Aperture-based MIME type detector with a Tika-based one

This required quite a bit of dependency gymnastics, since Tika has quite a few more transitive
dependencies than the Aperture library (which we had successfully pared down several years ago).
Tika references about 25 dependencies (including transitive dependencies), but this was reduced
in 'modeshape-jcr' to about 8 for basic MIME type detection. Note that Tika usually includes
two BouncyCastle libraries in its dependencies (used for encrypted PDFs, among other things),
but ModeShape intentionally excludes these (as we don't want to ship or depend on any
security-related JARs).

Not only do we get Tika's substantial MIME type database, we've made it possible for users
to edit the 'org/modeshape/custom-mimetypes.xml' file and provide the updated one on the application
classpath. What goes in that file will overwrite all of the other sources (namely Tika's built-in
file and its customization file, both of which are to be found on the classpath), which means
it's easiest to simply provide an updated version of this file at 'org/modeshape/custom-mimetypes.xml'.
Be sure to not remove any of the (few) customizations that ModeShape includes - those are important.

As we upgrade Tika, we'll get updated versions of the media type data. This is far more preferable
than having a ModeShape-specific version.

The MIME type related interfaces in ModeShape's public API (e.g., 'modeshape-jcr-api') have been removed.
These were added sometime in one of the 3.0 releases, so removing them will not introduce compatibility
issues for users.

Instead, we've decided to get out of the MIME type detection framework business, and have decided
to switch to Tika for all MIME type detection. In fact, you can still write your own MIME type detector,
but you do that by implementing Tika's interface and reference the implementation class(es) in the
corresponding service loader file in your JAR. (See the TIKA documentation for details.)

However, internally we still have an abstraction. This is because it is possible to remove the Tika
(and transitive dependencies) from a ModeShape installation, as long as your applications will not
expect any kind of automatic MIME type detection. This is a perfectly valid use case: for example,
using a repository to store data and do not store files (and don't use sequencers).

The AS7 kits required a bit more modification. There is now a new AS7 module for 'org.apache.tika'
that contains all of the JARs, and this is used by the ModeShape module and by the Tika text extractor
module.

All unit and integration tests pass with these changes. Several new tests were added.
MODE-1639 Minor improvements and fixes

A log message is output when no Tika mime type detectors could be found (meaning Tika is not on
the classpath), stating that automatic MIME type detection will be disabled. Also ensured that
the input stream used by Tika is always closed.

All unit and integration tests pass.
MODE-1639 Added log message.
MODE-1563 - Ported and updated graph xml import handler to 3.x
MODE-1563 - Added JCR integration for  the initial import handler
MODE-1563 - Added initial content test case involving repository restart
MODE-1563 - Integrated the initial content feature with the AS7 subsystem, including an integration test
MODE-1563 - Added mechanism for executing repository initialization operations only once (the first startup of an empty repository) and moved the initial content import into that section.
In addition, had to correct all the tests which make assumptions about the/ jcr:system content.
MODE-1649 Added support for using programmatically-created Infinispan components

Changed LocalEnvironment to enable easily using Infinispan cache and cache containers
instances. Also added more documentation.
MODE-1613- Fixed caching of node paths (via parentReferenceToSelf) in the case of SNS. The solution was to check that the parent of the actual cached children reference isn't stale.
MODE-1563 Corrected compiler warnings and JavaDoc errors.
MODE-1646 REST client can now be used to talk to 3.x and 2.x servers

Because of the improvements/changes in the RESTful API in 3.0, using the REST client required using slightly
different URLs to talk to 3.x vs 2.x servers. The reason is that the REST client still uses the older REST API,
and the URL for the older API is different on 3.x servers.

Although it was not feasible to transparently and automatically discover the correct URL given the actual server
the client talks to, it was possible to add a new method that does this. There is now a "validate(Server):Server"
method on the IRestClient interface, and this method can be used to validate a Server instance with a normal
URL (that is, excluding the API version qualifier) based upon the actual server. The method returns a new
Server instance that should be used for all subsequent communications.

Note that clients that don't take advantage of this new method can still work, as long as the URL ends with "/v1" for
3.x servers.
MODE-1648 Added several Maven BOMs for ModeShape clients

This commit adds several Maven BOMs that make it much easier for Maven-based applications and libraries
to add the necessary ModeShape dependencies as a consistent stack with the correct versions of ModeShape
components and third-party dependencies.

Unfortunately, I couldn't find a way to make the existing parent POM file extend or use these BOMs.
Therefore, the parent BOM and existing parent POM both contain properties defining the versions of all
dependencies. (Note that the BOMs should not extend the JBoss Parent POM, which our existing parent POM
does. This is the major source of contention.) However, if may be able to figure out how to share the
property definitions in a way that is transparent to clients that use the BOMs.

Note that these BOMs were tested by updating the example modules in the 'modeshape-examples' Git repository
and the module in the 'modeshape-performance' Git repository that uses the latest (post-Beta4) release of
ModeShape.
MODE-1619 - Added a new method on the IRestClient interface, which checks the existence of a file on the server
Also, fixed the log4j appender pattern for some of the test modules.
MODE-1648 Corrected the BOM POM's reference to the BOM parent.
MODE-1619 Corrected JavaDoc warnings/errors