DRYD-1575: Rename repatriationclaim to repatriationrequest

[mikejritter]

What does this do?

• Rename repatriationclaim to repatriationrequest
• Add id generator for repatriation request

Why are we doing this? (with JIRA link)
Jira: https://collectionspace.atlassian.net/browse/DRYD-1575

The new repatriation procedure was incorrectly specced out to be repatriation claim and needs to be repatriation request. This updates the names of the classes, packages, and schemas used to be repatriation request. The claim id generator was also being used previously and a new id generator for the repatriation request is being added.

How should this be tested? Do these changes have associated tests?

• Pull this and the related application PR
• Build and deploy a clean CollectionSpace instance
• Check that the repatriationrequests endpoint is still working

curl --user [email protected]:Administrator http://localhost:8180/cspace-services/repatriationrequests

• Further testing is done via the UI
• If desired, build with the necessary tenants and run the integration tests with mvn:test

Dependencies for merging? Releasing to production?
It's possible for the repatriationclaim to still exist if you didn't fully clean your environment.

Has the application documentation been updated for these changes?
No

Did someone actually run this code to verify it works?
@mikejritter tested against a local instance

[axb21]

@mikejritter I looked through this PR and it looks good as far as I can see. I didn't spot any typos or obvious errors. I did not pull the code and run it, so I haven't done a check at that level of depth. I'm happy to do that too if that's part of the usual PR review process.

Right now github offers "squash and merge" as the default merge option. Is that what we normally do, out of curiosity?

Update; I forgot to mention that I also grepped through the files in the branch for various forms of "repatriation claim" in filenames or in text content, and didn't find any.

[mikejritter]

@axb21 I think squash and merge is the only option for the CollectionSpace repositories which from my experience is what has been used in the past. Personally I sometimes do a rebase and merge depending on the PR. It might be worth discussing more as we could go over some of the workflows in general.

When adding new procedures pulling the code and running it would be ideal but obviously takes additional time (especially with how slow the startup is if all tenants are enabled for running the tests). It would be nice to have some CI that could show us the tests pass but with how CollectionSpace is deployed that isn't the easiest task at the moment.

I'll get this merged in.