Prevent duplicate DOI identifiers in public XML

[mjgiarlo]

TL;DR: minting DOIs within the ETD app causes duplicate DOIs to display on the purl page. For example: https://sul-purl-stage.stanford.edu/kx896yf4727

• Why do two DOIs show up there?
  • Because there are two /mods/identifier[@type='doi'] nodes in the public XML.
• Why are there two of those in the public XML?
  • Because the Cocina to MODS mapper in the PublicDescMetadataService first maps the DOI found in description.identifier (with type == DOI and source.code == doi) as a MODS identifier, and then PublicDescMetadataService#add_doi assumes there's no DOI there and schlepps the DOI from identification.doi into the MODS identifier.
• OK, but why are there two DOIs in the Cocina?
  • identification.doi is where H2 and H3 map the DOI, presumably so that we don't lose it later if a metadata refresh is triggered for the object.
• So then why is it in description.identifier?
  • Unlike our self-deposit apps, Folio is a system of record for metadata for ETD objects, and a requirement for the current ETD work cycle is to embed the ETD DOI into the ETD's MARC record which is loaded into Folio. Later in the ETD workflow once it's been cataloged, we refresh the ETD metadata from Folio which maps the DOI into description.identifier.
• Do we really have two different spots to record DOIs in Cocina?
  • Yes, we do. I've checked with @arcadiafalcone and she confirms this is intended.
• Is there a better way to deal with this?
  • Maybe. I figured this small PR would be a concrete way to start talking about this at least.

[mjgiarlo]

This is unrelated to my change, but I got annoyed by this test failing when the suite was run in a certain order (--seed 51784) due to this test not cleaning up after itself.

[jcoyne]

How/where is this causing a problem? Can you share an example?

[mjgiarlo]

@jcoyne 💬

How/where is this causing a problem? Can you share an example?

Just finished writing it up: #1031 (comment)

[jcoyne]

Thanks @mjgiarlo that's indeed helpful.