If the property sasl.proxyAuth is set to true, then administrative users can
authorize as any user on the system. This is convenient for testing, and to
manipulate other users' accounts.

An admin can, of course, change passwords anyway, so this doesn't reduce
security much, but is off by default in any case.

Testing is problematic since I can't actually find a client which allows this.

Seems to have been left as the Impl class rather than the Interface itself.

Not included in the original PR, and to my shame I hadn't noticed.

Fix filter ordering and admin console NPE

OF-913 Treat lib/log4j.xml as a config file in installers

Make module loading driven by a file

OF-477 Correct SASLserver to use consistent digest-uri

Deprecate the User Service and MUC Service Plugin.

Addressing DIRMINA-1012

Where ioSession.getRemoteAddress() returns null, this can cause an NPE.

Private Storage should return an error if feature is disabled

Update the REST API plugin to version 1.1.0

OF-892: Adding Admin panel support for mutual authentication.

Order Fastpath Workgroups by Display Name

OF-883: Prevent sending data to known disconnected peers.

By closing a session when the new MINA inputClosed() handler is triggered, we run
the risk of sending data to the peer. As that peer is known to be dead, this is
pointless (and potentially dangerous - deadlocks have been observed that are likely
related to this scenario).

To prevent sending data during session closure, the close() method has been
overloaded with an argument that indicates if the peer is known to be dead. When
set, its implementation will not attempt to send data.

OF-910 - Error stanzas to MUC room should remove occupants

Currently, only stanzas containing errors of type cancel will cause the
occupant to be removed, however this doesn't appear to catch and remove many
occupants in practise.

This patch therefore removes occupants from the service on any message or
presence error stanza, irrespective of the error type. IQ stanzas do not
trigger the same response, as these may be due to lack of client support
rather than a vanished occupant.

Two additional fixes that relate to OF-883

The close listeners should not be called from within a synchronized block.

When a connection is closed, several events can be involved (and can be triggered).
Some of these events will attempt to close the connection (if it hadn't been already).
This, at best, least to multiple invocations of close-listeners. At worst, a loop of
close-calls is created.

This commit replaces the two-way boolean that guards closure (isClosed) with a
three-way guard. Now, a distinction is made between between a connection that is
closed, and one that is closing.

Additionally, some null pointer guards have been added, as I've seen those pop up in
my local logs during development.

OF-883: Compensate for new half-duplex close of TCP channel in MINA

MINA 2.0.8 introduces support for half-duplex close of TCP channels (see DIRMINA-785).
As part of this change, IoHandlers got a new method. The default behavior of the
IoHandlerAdapter closes the MINA session when this handler is triggered. However,
without an Openfire-specific extension (in ConnectionHandler), this fails to close
Openfire-maintained resources. As a result, CPUs could start to spin in NIO code,
resulting in 100% CPU cycles.

To fix this issue, ConnectionHandler now overrides the default functionality and
triggers a normal closure of the session (both in Openfire as well as MINA context).

Additionally, to prevent the CPU spin, MINA sessions need to be closed synchronously
(as opposed to the async closure Openfire had up until now). I cannot quite explain
the need for this change, other than a suspision of race conditions in the async
setup.

ofmeet plugin version 0.1.8

Fixed issue with room locking not working
Added conference UI customization to Meetings Settings Admin web page
Updated Jitsi Videobridge

ofmeet plugin version 0.1.7

Logs openfire meeting audit events with Openfire security auditor
Logs meeting SIP calls via SIP plugin
Added support for audio conferencing meetings (no video)
Updated Jitsi Videobridge

Following suit with Users/Groups, Workgroups should order in alpha, shouldn't they?