Infrastructure

Here's the scenario for sample guid 'knb-lter-sbc.40.2':
- It is an EML 2.1.0 document with embedded access control rules that use the "denyFirst" permOrder are added the a MN instance of Metacat.
- System Metadata for access control does not know about nor care about the permOrder that Metacat uses to record access control.
- CN-unm gets this object from the MN and adds it to it's store - the System Metadata is immediately replicated to the other CNs (CN-ucsb and CN-orc) via the shared Hazelcast System Metadata map and then the EML file is replicated to them via Metacat replication.
- Upon EML replication to these other CNs we already have System Metadata (including access control rules with permOrder=allowFirst) recorded.
- The EML is parsed on the replica CNs and the access control rules embedded in it (permOrder=denyFirst) conflict with those that already exist from the prior System Metadata replication (where permOrder=allowFirst because that was what we chose as the default for System Metadata in Metacat).
- This makes Metacat's xml_access table inconsistent because we end up with a mix of denyFirst and allowFirst for the same guid (in fact this should not even be allowed to be inserted in cases like this, but that's a separate issue).

This "solved" by ignoring EML access control rules in the way described.