Support multiple DOI servers

[josegar74]

This change request allows to configure multiple DOI publications servers. A new maintenance for DOI servers has been added in Admin console > Settings > DOI servers:

A DOI server can be configure to manage only the metadata owned by certain group(s).

If the metadata can be published to multiple servers, it is provided a select list to choose the server where to publish the metadata:

A Java migration step from the old settings for the DOI server is provided to create a default DOI server if the DOI publication settings are defined. An alternative SQL migration is:

INSERT INTO doiservers (id, name, description, url, publicurl, landingpagetemplate, username, password, pattern, prefix)
SELECT nextval('doiserver_id_seq'), b.value, '', c.value, d.value, e.value, f.value, g.value, h.value, i.value FROM
   (SELECT value FROM settings WHERE name = 'system/publication/doi/doiurl') AS b,
   (SELECT value FROM settings WHERE name = 'system/publication/doi/doiurl') AS c,
   (SELECT value FROM settings WHERE name = 'system/publication/doi/doipublicurl') AS d,
   (SELECT value FROM settings WHERE name = 'system/publication/doi/doilandingpagetemplate') AS e,
   (SELECT value FROM settings WHERE name = 'system/publication/doi/doiusername') AS f,
   (SELECT value FROM settings WHERE name = 'system/publication/doi/doipassword') AS g,
   (SELECT value FROM settings WHERE name = 'system/publication/doi/doipattern') AS h,
   (SELECT value FROM settings WHERE name = 'system/publication/doi/doikey') AS i;



DELETE FROM settings WHERE name LIKE 'system/publication/doi/%' and name != 'system/publication/doi/doienabled';

Checklist

• I have read the contribution guidelines
• Pull request provided for main branch, backports managed with label
• Good housekeeping of code, cleaning up comments, tests, and documentation
• Clean commit history broken into understandable chucks, avoiding big commits with hundreds of files, cautious of reformatting and whitespace changes
• Clean commit messages, longer verbose messages are encouraged
• API Changes are identified in commit messages
• Testing provided for features or enhancements using automatic tests
• User documentation provided for new features or enhancements in manual
• Build documentation provided for development instructions in README.md files
• Library management using pom.xml dependency management. Update build documentation with intended library use and library tutorials or documentation

[sonarcloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud

[sonarcloud]

Quality Gate failed

Failed conditions
0.0% Coverage on New Code (required ≥ 80%)

See analysis details on SonarCloud