OF-1332 Update MySQL JDBC client to latest version.

OF-1310 Fix removal of last item of pubsub node

OF-1326: Improve sharing of the BOSH context

OF-1277 -- Change setting name to Invisible Login and Status

The Openfire plugin developer guide states that 'additinal' files should be in /classes/. Apparently, the old Ant script also included any files in the /src/. The new Maven structure does not.
To work around compatibility issues, code that was in /src/ is now moved to /classes/. This should work with both Ant, as well as Maven.

Additionally, this plugin now makes use of the new HttpBindManager API for registering contexts with the BOSH context. I do wonder if this plugin has any reason to be here though. Can't it just run its own embedded Jetty server?

Intead of using a parent context, a collection of Jetty handlers can be used to dynamically add/remove functionality to the BOSH context.

This commit replaces the parent context instance with a ordered list of handlers, which will attempt to process a request by:

1. Checking if this is a BOSH request
2. Checking if this is a request for BOSH metadata
3. Check if an extension was provided that can handle the request
4. Try to serve static content as a last resort.

In step 3, a collection of handlers is used, that can be modified at runtime. This allows plugins to register/remove handlers.

The entire collection of handlers (1 to 4) is maintained with a lifecycle that's different from the embedded Jetty server that uses them. This
allows the collection to survive a server reconfiguration, as well as act independent of the 'enabled' state of the BOSH service.

* OF-1325 -- Implement separate History settings in Client Control

* OF-1325 -- Implement separate History settings in Client Control

* OF-1325 -- Implement separate History settings in Client Control

Openfire repeatedly searches for the same UserDN values. This cache should alleviate the backend storage and improve performance.

OF-1324 limit outbound s2s queue

Non-functional changes

These add nothing, but warnings in tooling.

These statements do nothing but generate warnings. Easily fixed.

Javadoc comment are dangling if they don't belong to any class, method or field. For example a Javadoc comment in between method declarations that have their own javadoc comments.

These generate needless warnings, which are in most instances easily solved. By far most problems occur in the license block that's in most files.

This commit adds an upper-limit to the amount of stanzas that can be queued in an outgoing
session promise. Any data that won't fit in the queue is rejected immediately. Note that
this can lead to a situation where later stanzas are rejected before stanzas that or sent
earlier (but got in the queue).

OF-1311: Don't assume values are Strings.

OF-1321: Proper null-check to avoid stacktrace with stale session.

By default, the Maven structure uses the Maven artifactId value as the name for a plugin.
Maven artifactIds typically include tokens that will cause problems, such as dashes and dots.
The plugin name is used in various places, that all have limitations: filenames (the jar file
itself, the i18n files), package names (for the java files generated from JSPs), etc.

This commit allows the name of the plugin to be overridden using a maven property 'plugin.name'
and includes instructions on what the best format is.

For plugins to be able to use the tags used in the admin console, the tags should be distributed in a library. By making this library a Maven module, plugins can define the library as a dependency.

Note that the admin.tld file is duplicated, but *slightly* modified in the Maven module: the path of the tags is different (META-INF vs WEB-INF).

The HSQLDB library that ships with Openfire (for Ant) is newer than the
dependency that's defined in Maven. This introduces a compatibility issue
at runtime:

> org.jivesoftware.database.SchemaManager - Unexpected token: FILES in statement [ SET FILES]

The difference is likely an oversight, caused by us taking a very long time
to merge the Maven PR. At the time it was created, the dependency was still okay.

The Avalon framework is a dependency of the Proxool Maven artificat, but was
never included as a library to Openfire prior the move to Maven (so, we can
do without).

The Avalon dependency itself has a dependency of servlet-api 2.3, which is
unwanted, and causes issues when compiling JSPs.

Previously, the openfire-plugin-assembly artifact replaced the default artifact. When using
plugin project as a Maven dependency, this causes oddities: the dependency still is a JAR file,
but does not conform to a standard archive. This results in missing classes. Instead, this commit
retains the original project artifact. This is expected to be more useful.

Sadly, we appear to can pick only one of these options:

- Attach the openfire-plugin-assembly artifact (making it referencable)
- Define a finalName for this artifact (<artifactname>.plugin)

Both options appear to be mutually exclusive.

More annoyance is prevented by giving the plugin jar file a 'proper' name, I suspect, which is why
I opted for doing that. For the other option, set 'appendAssemblyId' to true, and remove the
'attach' element of the 'make-assembly' block.

The removed openfire-plugin-jar assembly does not appear to have a practical purpose: it builds a
jar file that is pretty similar to the standard artifact (it misses some metadata, and its final
name is different). Removing this assembly reduces complexity, at the cost of a benefit that I
cannot see.

The build plans for the plugins should not inherit from the parent project, as this
ties their existence in with our parent project. Third party developers cannot do
this (without modifying the parent project structure). We should facilitate third
party developers, and use the same tools as we provide them.

This commit removes the parent/child dependencies between the top-level parent POM
and the plugins POM. There still as a parent/child dependency between the plugins
POM and each individual plugin.

Although I'm not sure this change is a complete solution, it is aimed to more closely
represent a development setup in which a third party developer might find itself. To
create a plugin of their own, they can now:

 - Use our 'plugins' module directly (define it as a parent)
 - Replace our 'plugins' module by a proprietary one (when developing multiple
   proprietary plugins).
 - Take most POM definition from our 'plugins' module and merge that with a new
   stand-alone plugin project.