Metacat

for testing: limit and randomize the docs to generate metadata for

FOR TESTING ONLY: limit number of records to 100 so that we can get an estimate

update the memberNodeId in existing system metadata only after the register/update is successful with the CN -- we can avoid unneeded SM updates in cases when the register/update fails because we gave the CN bad info that it rejects.
https://redmine.dataone.org/issues/2308

include member node id text field now that the CN is not assigning random Ids.
https://redmine.dataone.org/issues/2308

1. lookup and use the guid when processing obsoletes/obsoletedBy entries -- had previously been assuming localId==guid but now that we have introduced DOIs as part of the Metacat upgrade process, we may have DOIs for the guid that map to localIds.
2. base ORE guids on the localid of the data package they are describing and not on their DOI -- otherwise we might mash up the DOI prefix (or other id scheme that we are unaware of). By using resourceMapPreix + localId we are sure to have a valid localid and guid for the ORE map we create and add to the system

use updated authorization policies as discussed in:
https://redmine.dataone.org/issues/2277
and
http://epad.dataone.org/20120131-authn-authz-questions

refactor D1-specific upgrade utilities into their own package

remove createAndInsertSystemMetadat() method that acts on a single localId -- incorporated this into the localId-list-based method.

refactor IdentityManager.createSystemMetadata(sm) to be insertSystemMetadata(sm) so that it is clear that this method inserts the SM object into the backing store. This differentiates it from the "generation" methods we use when we need to create SM about pre-existing objects or objects we get from non-D1 api calls.

generate SystemMetadata during D1 registration (not 2.0.0 upgrade). This process runs in a thread and updates a metacat.properties value when it is complete.