Duplicate data from an existing Item to a new WorskpaceItem, aka clone/copy item

[MMilosz]

References

• Fixes Copying existing item  dspace-angular#1757
• Angular PR Duplicate data from an existing Item to a new WorskpaceItem, aka clone/copy item dspace-angular#3076

Description

This PR introduces the ability to create a new WorkspaceItem by reusing properties from an existing Item, kind of like how versioning works now, but resulting in a partially completed edit form of a new Item. Some existing code from the versioning infrastructure was adapted and integrated as two new methods, copy and clone, within the ItemService, and tweaked, just to make things work more smoothly.

Here's a preview:

dspace_clone_item_feat.mp4

Instructions for Reviewers

On the REST side:

Example request (endpoint, header, body):

POST /api/submission/workspaceitems?owningCollection=:collectionUuid
Content-Type: text/uri-list

http://localhost:8080/server/api/core/items/:itemUuid

Response should show a new WorkspaceItem with some of the metadata copied from the specified :itemUuid. Although some of the metadata will be omitted to prevent duplicates or multiple values in places they shouldn't occur – see nonCopyableMetadataFields in core-services.xml.

On the Angular side:

• Login as admin and either deposit a new item or locate an existing one.
• Navigate to the item management page (edit -> status).
• Between move and delete, a new button should be visible for cloning the item. Click it, select any collection, then click save.
• The browser should redirect the user to the edit form, similar to what happens after creating a new item. However, most of the metadata should be copied from the previous item.

Checklist

• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & integration tests). Exceptions may be made if previously agreed upon.
• My PR passes Checkstyle validation based on the Code Style Guide.
• My PR includes Javadoc for all new (or modified) public methods and classes. It also includes Javadoc for large or complex private methods.
• My PR passes all tests and includes new/updated Unit or Integration Tests based on the Code Testing Guide.
• If my PR includes new libraries/dependencies (in any pom.xml), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.
• If my PR modifies REST API endpoints, I've opened a separate REST Contract PR related to this change.
• If my PR includes new configurations, I've provided basic technical documentation in the PR itself.
• If my PR fixes an issue ticket, I've linked them together.