Add support for the gitlab container registry API

💡 Context

There is an ongoing migration in the Container Registry to move data to a database. We are now in the phase where we can start moving existing container images.

This phase is going to be driven by Rails. Basically, this means that Rails will inspect the existing container repositories, pick the next eligible one and call the container registry API to start the migration process.

The migration operation is a two step process. This means that rails will get notified when a step is completed.

We are starting implementing the rails changes around this effort.

This MR is one of the very first MRs. Its focus is adding support for the new endpoints that will be available in the Container Registry API to start those two migration steps. This is issue #349741 (closed).

Now the Container Registry API is segmented in different parts:

1. The API that is OCI compliant
2. The additional API that has been added for GitLab needs (including the migration)

Any /v<X>/ prefix is the OCI spec (1.) and (2.) is basically prefixed with /gitlab/v1.

With this MR, we are going to add a new client along the existing one to support the API endpoints of (2.).

⚔ Design choices

We could simply add the related methods in the existing client class.

We decided to do otherwise. We currently have container registry features detection that will ping the Container Registry API to "discover" what is available. This result will then be saved in the application settings (under container_registry_features).

With that in mind, we decided to:

• Update the features detection to include the gitlab-api detection.
• Create a new dedicated class for the container registry client.
  • That class will have the related functions that will be mapped to the gitlab-api endpoints
  • This new client class is instantiated within ContainerRegistry::Registry which hold the original and the gitlab api client instances.
• Update the ContainerRepository model so that we can call the added gitlab-api endpoints through the gitlab_api_client instance var.

Given that for now, we're adding the migration functions only and those are only used on gitlab.com, those new methods on the ContainerRepository model will only work on gitlab.com

🔬 What does this MR do and why?

• Update UpdateContainerRegistryInfoService to detect the gitlab-api feature
• Introduce ContainerRegistry::GitlabApiClient with
  • Methods necessary for feature detection
  • Functions that are mapped to the new endoints on the gitlab API.
• Introduce ContainerRegistry::BaseClient as a root class for both client classes.
  • This is to centralize all the common logic and vars. Among other things, all the interactions with faraday.
• Update ContainerRepository with two methods:
  • migration_pre_import which starts step 1 of the migration
  • migration_import which starts step 2 of the migration
• Update/create the related specs

🖼 Screenshots or screen recordings

n / a

🔧 How to set up and validate locally

1. Check out the container registry project and build the binaries with $ make
2. Update <gdk_root>/registry/config.yml with:

   database:
     enabled: true
     host: <path to gdk root>/postgresql
     port: 5432
     user:
     dbname: registry
     password:
   gc:
     disabled: true # just to reduce the noise

3. Connect to psql with $ gdk psql
4. Create the registry database with CREATE DATABASE registry;
5. Execute the registry migrations within the container registry project with : $ ./bin/registry database migrate up <path to gdk root>/registry/config.yml
6. Start the container registry from its project with : $ ./bin/registry serve <gdk_root>/registry/config.yml
7. Ensure that you have no errors in the logs

We can't test the new gitlab api endpoints but we can verify the features detection.

1. In a rails console, execute

   UpdateContainerRegistryInfoService.new.execute
   Gitlab::CurrentSettings.container_registry_features
   # => ["tag_delete"]

2. Check the registry features again:

   Gitlab::CurrentSettings.container_registry_features
   # => ["tag_delete", "gitlab_v1_api"]

🚥 MR acceptance checklist

This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.

• I have evaluated the MR acceptance checklist for this MR.