Automatically enable metadata block when extracting metadata from FITS, NetCDF, or HDF5

[pdurbin]

• if NetCDF/HDF5 detected and if lat/long
  • continue to create aux file
  • enable geospatial block
  • populate bounding box
• if FITS
  • enable astro block
  • populate astro fields
• if multiple files, create that many instances of the fields (e.g. bounding box)

[qqmyers]

This seems like it conflicts with the design of allowing collection admins to specify which blocks are on. Assuming one is OK with that:

• if ~ingest becomes modular, can other plugins turn on other blocks?
• if ~ingest is enhanced to allow it to be done remotely, I would expect Dataverse would get new metadata via the API - do we then need a special ~permission for ingesters to use the API (and turn on these blocks)?

Also - is there a potential interaction with #9388? I.e. I assume the reason that these blocks aren't on by default is because curators don't want users to see them. If these blocks were configured as system blocks, they would be hidden but would still be available (and in the future remote ingest would just need a key to add to them). This would also mean a key is required to change the values created automatically, which helps preserve the link between metadata and file contents but might also confuse users. A downside with the PR as is is that there is no way to have one block available for user input via the UI in some collections and to be protected/hidden in others and the astronomy and geospatial blocks today seem intended to serve both purposes (automated and manual inputs). Perhaps future work re #9388 could allow values added with a key to be protected while making it optional for manual/editable values to also be addable.

[mreekie]

Grooming:

• Added deliverable label

[cmbz]

2024/01/08: Closing due to complexity with UI and disagreement related to how automatic the process should be. We can reopen or create a new issue once the SPA Beta is available.