PID Assignment in Backend

Related to https://gitlab.hzdr.de/hub-terra/sms/frontend/-/issues/68

As a scientist i am able to give to already exisiting device and platform a PID by Handle service. In case of UFZ the GWDG PIDINST service is used. As a User i have a simple button to click on to get an PID. Then the PID is created at Handel-Service and the PID ist shown in the device/platform tab. If user changes any PID releated attributes an automated PID-Update is triggered. PIDs should be available only fpr internal and public devices/platforms. The creation of a PID should be triggered by User for now. (for testing it will be okay, to create the PID automaticly if a new device/platform is created)

• Related requirements: https://confluence.digitalearth-hgf.de/display/HUB/PID+Ideen@UFZ (Mapping PIDINST Metadatenschema - SMS) (Mandatory and Recommended)
• Add new Mandatory fields to SMS owner and manufacturer

TODO:

• Test the PID test access by backend implentation (create, update) Credendials @kotyba.alhaj-taha @daniel.sielaff
• Implement the PID create-Function in a way that different Handle-service can be used depending on the hosting institute [x] Implement the PID delete-Function in a way that different Handle-service can be used depending on the hosting institute (if an entity is hard deleted in backend the PID delete has to be triggerd
  • check if PID exists
  • if yes, delete the PID by request
  • Reuse the Approach of Nils search engine
• Implement the PID update-Function in a way that different Handle-service can be used depending on the hosting institute
  • automatic trigger a PID update request if an entity is changed by updates(edit) if a related mandatory, recommended field is changed or initial set to value
• add recommended fields to the PID-process if available in SMS
  • dont add owner mail use given_name instead for owner.
  • add model & modelName ()
  • add Description
  • add InstrumentType & instrumentTypeName (based on manufacturer name..)
  • add MeasuredVariable (property_name) maybe serialized string if more than one property
  • add AlternateIdentifier (serial number)
• clearify the frontend implementation
• maybe,change the API for triggering the PID creation
• change the create workflow
  • trigger by sms-endpoint request (default by id&type-endpoint)
  • post-request to GWDG-handle-service
  • store the PID directly in backend
  • response to frontend including PID-Handle/(new: PID-URL to give the user a direct link to the PID-Provider)
• use the productive credentials and service in productive environment
• for productive system it should be possible to disable the PID Feature by env-variable (f.e. usePID=true/false)