API call to deaccession datasets

[pdurbin]

Deaccessioning of datasets was implemented in #600 and related tickets but it's a GUI-only operation.

The Data Deposit API in DVN 3.x supported deaccessioning but in a meeting we talked about deprecating this feature because a reason for deprecation can not be given. For now, when this operation is attempted we'll link to this ticket or otherwise indicate that is or will be a feature of the "native" API.

Selfishly, I'd like an API call sooner rather that later so I can easily test deaccessioning programmatically.

[pdurbin]

I just wanted to mention that when hacking around on Private URL in #1012 today I definitely noticed that there is (unfortunately) business logic having to do with deaccessioning that exists only in the GUI, especially setDatasetVersionDeaccessionReasonAndURL at https://github.com/IQSS/dataverse/blob/v4.3/src/main/java/edu/harvard/iq/dataverse/DatasetPage.java#L1994 but perhaps other places as well. Code like this needs to be centralized so it can be used from the API as well.

In #2746 we started an effort toward automated testing and the inability to deaccession datasets via API inhibits our ability to test in this area.

[kcondon]

We should do a gap analysis between UI and API to catch any other missing endpoints.
Seems to have value for automated testing, code refactoring, and possibly more comprehensive future integration with other publishing systems.

[pdurbin]

For the gap analysis, it's also impossible to restrict files via API: #2497. This makes it impossible to write API tests for this. I'm pretty sure a lot of guestbook stuff is also GUI only.

[pdurbin]

Closing in favor of this list I'm maintaining: No functionality should be GUI-only. Make all functionality reachable via the API #3440

[pdurbin]

The spiritual successor of this issue:

• As a data curator, I'd like to be able to use the GUI to deaccession multiple datasets #8132