Add maven virtual registry crud endpoints (Registry)

🔭 Context

With Maven virtual registry MVC (API only interactions) (&14137 - closed), we're starting the work on Virtual Registries. Virtual Registries is a feature that could be described as the evolution of the dependency proxy idea: having the GitLab instance play man in the middle between clients and artifacts registries. Artifacts can be any kind, but we're going to focus on packages and container images, starting with Maven packages specifically.

The maven virtual registry mainly consists of 3 entities (models that are backed up with database tables): Registries, Upstreams, and CachedResponses. For each entity, we need to support crud APIs, so users can list/create/update/delete those entities in their groups.

In this MR, we start with adding the crud endpoints for the 1st entity: Registries. 2 subsequent MRs should follow to add the other 2 entities crud.

What does this MR do and why?

Adding the following endpoints & their specs:

Registries

Route	Notes
GET /api/v4/virtual_registries/packages/maven/registries?group_id=<root_group_id>	Get the list of all maven registries (only 1 in this scope).
GET /api/v4/virtual_registries/packages/maven/registries/:registry_id	Get a specific maven registry
POST /api/v4/virtual_registries/packages/maven/registries	Create a specific maven registry. Attributes will be mainly the cache settings.
PUT /api/v4/virtual_registries/packages/maven/registries/:registry_id	Updating a specific maven registry.
DELETE /api/v4/virtual_registries/packages/maven/registries/:registry_id	Delete a specific maven registry.

The attributes that can be passed for the POST and PUT requests:

• (POST only) group_id. The root Group id.
• cache_validity_hours. 0 or positive integer.

MR acceptance checklist

Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

Screenshots or screen recordings

N/A

How to set up and validate locally

Numbered steps to set up and validate the change are strongly suggested.

1. Enable the feature flag : Feature.enable(:virtual_registry_maven).

2. Have a PAT and a root group (any visibility) ready.

3. Create a new registry using the new POST /api/v4/virtual_registries/packages/maven/registries endpoint:

   curl -i -H 'Content-Type: application/json' \
      -d '{ "group_id": <root_group_id>, "cache_validity_hours": 24}' \
      -X POST \
      http://root:<PAT>@gdk.test:3000/api/v4/virtual_registries/packages/maven/registries

4. List the available registries of the group using GET /api/v4/virtual_registries/packages/maven/registries endpoint:

   curl -i http://root:<PAT>@gdk.test:3000/api/v4/virtual_registries/packages/maven/registries?group_id=<root_group_id>

5. Get the details of a specific registry using GET /api/v4/virtual_registries/packages/maven/registries/:registry_id endpoint:

   curl -i http://root:<PAT>@gdk.test:3000/api/v4/virtual_registries/packages/maven/registries/<registry_id>

6. Update the cache_validity_hours attribute of the registry using PUT /api/v4/virtual_registries/packages/maven/registries/:registry_id endpoint:

   curl -i -H 'Content-Type: application/json' \
      -d '{ "cache_validity_hours": 0}' \
      -X PUT \
      http://root:<PAT>@gdk.test:3000/api/v4/virtual_registries/packages/maven/registries/<registry_id>

7. Delete the registry using DELETE /api/v4/virtual_registries/packages/maven/registries/:registry_id endpoint:

   curl -i -X DELETE http://root:<PAT>@gdk.test:3000/api/v4/virtual_registries/packages/maven/registries/<registry_id>

8. You can play around with different scenarios: passing invalid parameters, or invalid authentication token.

Related to #467979 (closed)