Container repository details GraphQL API

🌲 Context

This MR is part of my effort to "improve Packages APIs" by porting the Rest API to GraphQL.

This is my tiny stone to &2474 and to some extent to gitlab-com/www-gitlab-com#6476 (closed).

Today's subject: the Container Repository Details API!

In !44926 (merged), we added a GraphQL API to list the container repositories at the project and group level.

The next step (this MR), is to get the container repository details given a container repository id. The final goal is to allow the frontend build the container repositories UI on top of this API. That's why we're going to align with the UI's needs (for example, the UI needs a boolean flag indicating if the current user can or not delete a container repository) and not necessarily the Rest API.

Now, here is a bit of context behind container repository details. A container repository has an id, name, path but more importantly it has a list of tags. Now these tags are not stored on GitLab rails. They live in the Container Registry which means that access the tags list and their details will trigger some request to the Container Registry. We have to take a bit of care here as accessing the Container Registry can be somewhat slow (for now, improvements are on their way).

To give some numbers, let's say that we want to have the tags of a container repository with 50 tags and we want all the detailed information for each tag. The GitLab rails backend will make:

• 1 request to get the whole list
• 3 requests per tag
  • 1 HEAD on the manifest to get the digest
  • 1 GET on the tag manifest to get the config structure
  • 1 GET on the tag config blob

= 3 * tags_count + 1 = 151 network requests done 😱

⚔ Design choices

• We could update the graphQL type returned by the list query and put an optional filter to access a single container repository but it's not a good idea. This could let users list all the container repositories and get the details of all tags at once = 💥 🔥
• Instead, we're going to create a second query for container repository details. This way, it's impossible to list n container repositories and fetch their tags.
  • This query will use the global id of the container repository.
• For ~performance reasons, we're going to limit the max number of elements per page for tags and reduce it to 20 (down from 100, the default value). This way, the worst case scenario will do 41 requests to the container registry.

What does this MR do?

• Add a new container repository GraphQL query
• Add all the relevant types
  • To keep things simple, the detailed type will be an extension of the type used in the list API
• Add all the relevant specs
  • Introduced a json schema validation to assert to correct structure of the response

Screenshots (strongly suggested)

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• Separation of EE specific content

Availability and Testing

• [-] Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team