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.

Straightforward failure to escape in this debugging plugin.

* Add option to disable delayed delivery (XEP-0203)

This fixes some encoding issues, preventing LDAP users that have an '@' character in their username from becoming admin.

In an annoying quest to reproduce a bug related to JSTL and plugins I completely redid the MoTD plugin admin console page. I added CSRF protection to justify my changes.

Never did reproduce that bug...

* OF-1311: Allow lists to be stored in a property.

* OF-1312: Allow SASL mechanisms to be configured in the admin console.

A new property (ldap.encodeMultibyteCharacters) is introduced that controls if multibyte characters in LDAP search queries are escaped.

Escaping of these characters started with the fix for OF-830, which appears to have caused OF-1305. Although I can't say that escaping of characters is wrong (per RFC 4515), it does cause real-world problems.

This fix defaults to not encoding again (reverting back to the behavior pre OF-830, without affecting other changes made in OF-830).

RestAPI plugin, synchronizing invalid room state when creating a room in a clustered Openfire

When creating a room using RestAPI plugin, RoomUpdateEvent should be fired only after the room is fully processed/configured

* run `mvn versions:set -DnewVersion=4.2.0-SNAPSHOT`
* manually edited non-included plugins

This commit introduces some dependencies that were added to Openfire since the original Maven stucture was build. With these, the Maven build should compile again.

(dwr has transitive dependency to it)

The Maven structure is:
-/
--dbutil (used by xmppserver)
--i18n (used by starter and xmppserver)
--starter (launcher and starter package, startup.jar)
--xmppserver (nearly everything in the src dir, openfire.jar)
--webadmin (admin plugin)
--plugins
---broadcast
---...

I've also added Maven plugins to mimic partial behavior of the Ant build (copying dependencies, bin/conf folder, ...)

This commit addresses issues OF-546.

I reconfigured the pom.xmls to work with the existing directory structure, (instead of default src/main/java), so that the current src folder stays untouched.

What it can do:
- Run tests successfully
- Generate JavaDoc
- Assemble most plugin jars (without JSP)
- Assemble admin plugin (without JSP)
- Generate a source zip/tar.gz for distribution (as the download page offers it currently)
- Build the startup.jar and openfire.jar, copy it in the right directory, so that Openfire can be run with `java -jar startup.jar`

What it can't do:
- Build executables for every platform (e.g. install4j, *.dmg, ...)
- Build some plugins (e.g. ofmeet) due to non-Maven dependencies.

Todos:
- Fix these issues
- Move source code to the correct paths, e.g. /src to xmppserver/src/main/java

This was referenced by Openfire as dbutil.jar, but because this cannot be referenced via Maven Central, we add it as module for Openfire.

* OF-1299 / OF-1300: Fixes for XML Debugger plugin.

Causes the plugin to print the remote address, as well as less 'garbage' (compressed and/or encrypted data).

This reverts commit ffe14c90 and hopefully resolves OF-1263 and OF-1269

This reverts commit 508e39e2 and hopefully resolves OF-1263 and OF-1269

OF-1195 Correct SCRAM supported logic

* OF-1278 Recurse more sensibly in SCRAM code

Previously, we called setPassword if (and only if) there was a plaintext password present AND the configuration was for SCRAM hashed passwords only.

However, we would then retest to see if there was a salt present, and then recurse, if there was a plaintext password present.

This meant that if there were pre-existing users (with only plaintext or encrypted passwords) but with no SCRAM information, and the userInfo.salt was unset, recursion would continue indefinitely.

* OF-1278 Recurse more sensibly in SCRAM code

This patch further proofs against infinite recursion, and is more aggressive about SCRAMming pre-existing users.

Recursion is now prevented from being more than one deep, as designed.

Adding elements and attributes to the new element doesn't work, since reparenting the old elements generates an exception. This exception wasn't logged.

* Exception logged
* id attribute copied, if present.
* Elements copied deeply/properly.

Test stanza:

```
<message xmlns="jabber:client" to="blah@conference.cridland.im" type="groupchat" id="5260">
<body>This is a message with a label.</body>
<custom xmlns='tmp:custom'/>
<custom-attr xmlns='tmp:custom2' attr='value'/>
<custom-child xmlns='tmp:custom3'>
<child>element</child>
</custom-child>
<custom-text xmlns='tmp:custom4'>Text here</custom-text>
</message>
```