datanucleus: use persistence units

Based on the 2.11 release notes, a patch to embed the alarms service in dCacheDomain of system-test
was committed. The release notes claimed that there no longer was a requirement to run it in a separate domain.

Embedding it however broke the tests because the EnhancementHelper.registerClass() call for the XML database (alarms)
rejects other classes using the datastore identity, even though not destined for storage in that database.

The issue here, to quote the author of the code, is as follows:

"JDO comes with an auto-notify feature that will inform ALL interested parties when an enhanced class is loaded (so they can load up metadata for it). Since you have multiple PMF's then the MetaDataManager of each PMF are informed and they try to load it (since it is simply an enhanced class - can be used with any persistence environment that supports JDO). Since one PMF is for XML and it only accepts particular metadata then it rejects that class (for that MetaDataManager) by exception. DN 4.1 code simply logs a warning (instead of exception) that the class is not available for that PMF (so the user can fix their metadata if they want it to be available there)."

For fuller discussion, see http://www.datanucleus.org/servlet/forum/viewthread_thread,7815.

While an update to 4.1 will remove the failure, the better solution is the one we have adopted:
the suggested partitioning of all enhanced classes by persistence units (already used for the pinmanager).

Also makes the 'off' url for alarms a non-empty string; otherwise an NPE occurs during injection.

Target: trunk
Patch: https://rb.dcache.org/r/7517
Request: 2.11
Require-book: no
Require-notes: yes (in case 2.11 has been used already)
Acked-by: Gerd

RELEASE NOTES:  Fixes error when alarms XML database and TransferManager share the same domain.