category delta is handled in update, current tests pass, some TODO still
Merge remote-tracking branch 'origin/develop' into jira/NMS-6848
Merge remote-tracking branch 'origin/rc/stable/1.14.0' into jira/NMS-6848
not yet working, just doing some moving-things-around
Merge remote-tracking branch 'origin/rc/stable/1.14.0' into jira/NMS-6848
test the simple case -- working test case
NMS-5059/NMS-5266/NMS-6848 provisioning/category race conditions
add a log so we know what policies are being applied
fix JPA annotations to do what I meant
reformat source
Merge remote-tracking branch 'origin/rc/stable/1.14.0' into jira/NMS-6848
Merge remote-tracking branch 'origin/rc/stable/1.14.0' into jira/NMS-6848
reinstate update visitation
change %s to {} but leave otherwise alone
call visit on the DB node, not the new node
fix exception during NewSuspect scans
we should get an updated event, just not the category one
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