Updated log4j to 2.1-SNAPSHOT to fix problem where it throws an exception
during the static initializer of sun.reflect.misc.Trampoline. Fixes bug
NMS-6784.
update .marker-cluster div style
Improving the poller-test command to work better with advanced features.

The PSM requires to know the node's label in order to work with the
${nodelabel} placeholder for web-site monitoring. For this reason, the
implementation of the poller test has been updated to retrieve the
node's information from the database prior executing the poller test.
Merge branch 'jira/NMS-6861' into rc/stable/1.14.0
Add a null check in tooltip text for NMS-6627
NMS-6395 handle optional perl dependencies more gracefully
NMS-6848 fix Provisiond category-handling

Merge remote-tracking branch 'origin/jira/NMS-6848' into rc/stable/1.14.0

This change fixes a number of problems relating to categories and Provisiond.

* Provisiond now no longer removes and then re-adds categories between the
  import and scanning phases.
* Provisiond now handles nodes which have both requisitioned categories in
  addition to user-added categories in a sane way.
* Other miscellaneous fixes related to category scanning and provisioning.

From opennms-provision/opennms-provisiond/design.markdown:

Category Lifecycle
==================

Node categories present an interesting problem in that there are multiple phases of the import
and scan process that influence the categories a node should have, and it is problematic if
categories are removed and then re-added through different phases of a scan while they are being
used at runtime by the OpenNMS system.

To resolve this, we have the following design:

Import Phase
------------

During the import phase, the behavior differs depending on whether the node already exists in
the database (update), or doesn't (insert).

In the case of a new node (insert), Provisiond will add each requisitioned category to the
node before persisting.

In the case of an existing node (update), the node's list of categories will remain unchanged
until the scan phase.  Note that between this time and the time that the Scan Phase finishes,
updated nodes will contain any interface/etc. changes made by the requisition, but they will
*not* contain category changes.

Scan Phase
----------

At the start of the scan phase, the node object's "requisitioned categories" will be populated
using the list of categories from the requisition.  Then, during the scan phase, NodePolicies
will update these same "requisitioned categories", rather than addCategory() or removeCategory()
like the previous behavior.

When the scan phase has completed, the list of previously requisitioned categories will be
pulled from the database, and compared to the list provided by getRequisitionedCategories().
These 2 lists will be reconciled, adding and removing categories with addCategory() and
removeCategory() to/from the node as necessary.  The new list will be persisted back to the
database for the next scan.

Thus:

* if a requisition adds a category, it will be added to the node
* if a requisition removes a category, it will be removed from the node
* any categories added through other means (which weren't also in the requisition) will be left alone
a few updates to the design document
Merge remote-tracking branch 'origin/1.12' into rc/stable/1.14.0

Conflicts:
	opennms-services/src/main/java/org/opennms/netmgt/poller/MonitorTester.java
Fixing the instructions for enable logging on command lines.
Merge branch 'jira/NMS-6784' into rc/stable/1.14.0
Merge branch 'rc/stable/1.14.0' of https://github.com/OpenNMS/opennms into rc/stable/1.14.0
redundant junit dependencies
NMS-6848 fix issue with category event not firing
Merge branch 'rc/stable/1.14.0' of github.com:OpenNMS/opennms into 1.14.0
toString() cleanup and fix PollableNode.delete()