Without `level` at the end of the property, it doesn't work

Closes [BR-430](https://bonitasoft.atlassian.net/browse/BR-430)

Also remove all reference to the need to add Oracle drivers

covers [BPO-540](https://bonitasoft.atlassian.net/browse/BPO-540)

* avoid generating empty log files

'host-manager' and 'manager' webapps are not packaged within the bundle so
remove associated handlers that previously generated empty log files.
In addition, remove the 'localhost' handlers as no logger is associated to it.

* all logs in a single bonita.log file

This ensures that all logs of 3rd party libs are in bonita.log and simplify
logging configuration.

In the past, we have been forced to declare for most of 3rd party lib loggers
the right handler to ensure logs are generated in the bonita.log file. Most of
the time, this was done only after receiving external feedback on bug
investigations (information were lost or hidden in catalina log file).

Part of the work to hide Tomcat internals to the external world.

* comment AJP connector by default (follow tomcat changes)

this fixes CVEs, see
https://tomcat.apache.org/security-8.html

Closes [BR-408](https://bonitasoft.atlassian.net/browse/BR-408)

When using oracle and XA, there is an issue between Arjuna and Oracle that causes XAResource enlisting issue.
In order to avoid this issue when there is multiple XAResource registered, override XADataSource in commons-dbcp2 to make XAResource#isSameRM always return false in the case of Oracle database.

Add also integration tests on BDM

Relates to [BR-370](https://bonitasoft.atlassian.net/browse/BR-370)
Closes to [BS-19464](https://bonitasoft.atlassian.net/browse/BS-19464)

if activated

Closes [BR-353](https://bonitasoft.atlassian.net/browse/BR-353)

stax was duplicated, ignore the oldest version

for activation, remove it from lib/bonita, it was no used by the
transaction manager
ignore activation-api from transitive dependencies, its bundled by
jakarta.activation (api+implementation)

Relates to [BR-332](https://bonitasoft.atlassian.net/browse/BR-332)

Thomas Bouffard authored Jan 20, 2020 and Baptiste Mesta committed Jan 20, 2020

* use bonita-web-sp dependencies for the sp war
* bonita-war-sp: add console-server-sp extra dependencies
* remove libs already in lib/bonita
* ignore overlay when building bonita-war-sp

the overlay comes from console-server-sp.war that have
console-server.war as overlay. It was making lib present in community but not in SP to be copied in the SP war (forms-*.jar)

Co-authored-by: Baptiste Mesta <baptiste.mesta@gmail.com>

Thomas Bouffard authored Jan 15, 2020 and Baptiste Mesta committed Jan 15, 2020

Stop having bonita-web as parent
  - this added gwt dependencies to all modules
  - use bom for dependencies management instead

remove declaration of uid version as it is not used (confirmed by the version
which relates to bonita 7.6)

upgrade plugins versions to latest available
remove unused plugins
  - checksum-maven-plugin
  - jacoco-maven-plugin

update maven-compiler plugin configuration

Introduce bonita-war to replace all-in-one and war-server
  - the main change is to declare all dependencies in war-server to let maven
  resolve dependencies
  - only on community for now
  - previously, as we copied the lib from the web war and add the one for
  bonita-server, the dependencies resolution could not be properly done by maven
  So, now, just copy web resources first to create the initial war, then add all
  the lib to the war via full maven resolution

Simplify the bundle preparation
  - previously, it was done in several steps because we had the deploy and the
  wildfly bundles.
  - now, we create a 'tomcat distribution for bonita', used for both Community
  and Enterprise to remove duplication

Other changes
  - remove license files
  They are only packaged in the deploy bundle but not in the final tomcat one,
  so remove them
  - remove spnego jar from repository and get it as maven dependency
  - package: avoid warning on windows (outputDirectory)

Thomas Bouffard authored Jan 14, 2020 and Baptiste Mesta committed Jan 14, 2020

Simplify access to bonita by redirecting tomcat root to the bonita webapps.
This implies replacing the default tomcat ROOT webapps by a custom one in charge
of the redirect.

Part of the work to hide Tomcat internals to the external world.

It was not packaged in the bundle nor made available outside of this repository.
As of Bonita 7.10.0, it is now hosted in its own repository:
https://github.com/bonitasoft/bonita-user-application

Deploying extra webapp in the bonita bundle is not supported. However, if this
is needed, do it by dropping it in the webapps tomcat folder
Part of the work to hide Tomcat internals to the external world.

bonita-tomcat-juli module has been introduced in master, so the last merge
push it to the dev branch with the wrong version (7.10.x instead of 7.11.x)