getIterations() threw an exception which
caused early termination of the SASL exchange.

Spotted by Phil Roberts of Surevine Ltd.

This implementation is a backport from master to the 4.1 branch, of an API change that was part of OF-1353. OF-1020 needs this API. This specific implementation should not live outside of the 4.1 branch.

There's no point in offering in-band registration when the user provider disallows any modifications.

Fixing NullPointerException caused by having a mix of valid Groups and NULLs inside the result of getGroupsFromKeys

Openfire 4.2.0 will have the functionality that's now in the websocket plugin. As a result,
this plugin should not be used in Openfire 4.2.0. To facilitate this, we've defined a new concept
of 'priorToServerVersion' in OF-1353.

This commit defines that the plugin should only be used in Openfire instances prior to version 4.2.0.

This PR implements the missing code and fixes the issue

   @Override
   public ConnectionConfiguration getConfiguration()
   {
       // TODO Here we run into an issue with the ConnectionConfiguration introduced in Openfire 4:
       //      it is not extensible in the sense that unforeseen connection types can be added.
       //      For now, null is returned, as this object is likely to be unused (its lifecycle is
       //      not managed by a ConnectionListener instance).
       return null;
   }

This is a complex problem.  During setup, fetching xmppSettings from the session may fail due to an invalid session state maintained between the client browser and the server.  This is likely caused by a previous HTTPS session to the same server hostname setting a `JSESSIONID` that subsequently can not be overwritten by the current HTTP openfire-setup session.

This introduces i18n string `setup.invalid_session`

Usage of Mapped providers requires a lot of configuration, that should be documented. The documentation provided in this commit describes a common use case, in which admins are to be retrieved from the default providers, while regular users are obtained from an external system.

XMPP defines two configuration fields for password-protecting a room:
- one that defines if the room is password protected.
- another one that defines the password.

Openfire, internally, only stores the password, if password-protection is required.

Some clients send only a password, without explicitly defining the password-protection boolean. In such cases, Openfire should be somewhat flexible, and process the configuration form as intended by the user.

* OF-1343 added comments about changes in 4.1.5

* OF-1343 a note about new service behavior

The static web content handler is allowed to be null (when there's no static content to be served). In such case, the null-handler shouldn't be loaded in Jetty (which will throws nullpointers).

* OF-1342 Remove "Run Openfire" from the final step of the installer. Changed to "Start Openfire Service"

* OF-1342 Remove "Run Openfire" from the final step of the installer. Changed to "Start Openfire Service"

* OF-1349 Create separate Windows installer with and without JRE

This commit fixes a runtime problem caused by SortedSet usage with providers that are not Comparable. By using a different Set implementation, iteration order is predictable, without there being a need for providers being Comparable.

This commit adds some UX improvements to the 'edit group' page on the admin console.

Hopefully addressses UAC issues. Installs services on windows at install. Replaces launcher with starting service and launching web browser.  Adds option to create x64 installer for windows.

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.