Cleanup of DataCite registration implementation, add OnSuccess status

[landreev]

This is a followup issue to #5427

We've discussed some further improvements/safety checks to the DataCite registration process.

For example, it would be more prudent to actually read the response from the DataCite /metadata API and validate it; rather than rely on receiving a 200.
Some limit on the number of retries perhaps?
Review the transaction framework of the publishing process; makes sure nothing is left in a bad state when the publication process goes wrong due to the global id(s) registration.

Some overall cleanup of the code may be beneficial too... I may be missing something - but it's not immediately clear to me why we need the DOIDataCiteServiceBean and the separate DOIDataCiteRegisterService - ? It looks like duplication of code/more places for things to go wrong...

The code that actually talks to DataCite is isolated in DataCiteRESTfullClient.java btw; as of now - with the fixes in the PR #5428 - it is still possible to write some code that will call the DataCiteRESTfullClient.testDOIExists() directly, give it a junk string and get "true".

The above is just to open an issue; if anyone can think of things to further investigate and/or improve, please add.

[scolapasta]

Partially related: @michbarsinai and I had discussed adding to the Command Infrastructure the idea of "onSuccess". That is a method in the interface that the engine calls after the transaction of the execute method is completed. This would be for actions that are meant to happen outside the transaction, like indexing.

In this case, you could imagine the publish would succeed from the dataverse side and then the onsuccess would get called to index and call DataCite. Any issues there would get reported back somehow to an admin, but would not sop the publish from succeeding.

We could still do the onSuccess idea without having it be involved in published (in the case that we want publish to fail if there is an issue with DataCite). But It might be worthwhile to consider not failing for that reason as there is still value to publishing otherwise.

(the ui could be smart enough to also know once the success happen, in order to show if the pid was registered or to mark the citation as not yet ready - since the doi would not work)

[djbrooke]

@scolapasta @landreev - onSuccess is merged! Is it related enough that this can be closed?

[scolapasta]

No. The onSuccess issue handled the infrastructure to allow things like this to happen; it was a prereq for issues like this.

[cmbz]

To focus on the most important features and bugs, we are closing issues created before 2020 (version 5.0) that are not new feature requests with the label 'Type: Feature'.

If you created this issue and you feel the team should revisit this decision, please reopen the issue and leave a comment.