Refactor API tests to using JUnit5 + custom extensions

[poikilotherm]

Overview of the Feature Request

While hacking on code for #8250 I noticed some problems due to how API tests are currently done: creating collections, datasets, users and settings is mostly done within the test code itself.

This request is a request to:

1. refactor API tests from JUnit 4 to JUnit 5
2. create custom extensions to handle things like database settings, creation of resources
3. prepare the test code to be reusable with Testcontainers in Increase testability by using Testcontainers #8250

What kind of user is the feature intended for?
(Example users roles: API User, Curator, Depositor, Guest, Superuser, Sysadmin)

• Developer
• (Sysadmin)

What inspired the request?

Some tests failed when working on #8250 because of formerly unexpressed dependencies on setup and settings. As a root cause it became clear that a failing test not resetting a database setting can render other tests to fail.

This can be avoided by creating extensions that hook into the test lifecycles when necessary (@Before/@After is not flexible enough here!) and ensure settings are present (set if not not) and clean up after the test, independent of the outcome. This is MUCH easier with JUnit 5 than 4 (the successor has been designed exactly with this in mind), thus a small refactoring is necessary to move to 5.

The test code would also become much more readable when the repetitive task of creating test users, test collections and test datasets would not have to be repeated code within almost every test routine. Also leaving an inconsistent state when tests fail, as the cleanup is a part of the test.

What existing behavior do you want changed?

1. Move all *IT.java used in regular integration tests to JUnit5
2. Create JUnit 5 extensions for most important tasks (DB settings, resource creation)
3. Document this stuff in a dev guide section on how to write API tests
4. Update RESTassured from v2.4 to latest v4.4

Any brand new behavior do you want to add to Dataverse?

Not to application behaviour.

Any related open or closed issues to this feature request?

#8250