Embed project path in JWT tokens

Context

We need to be able to determine if a project has been locked for an ongoing "rename" operation on the registry side as discussed in container-registry#960 (closed).

In order to do that we first need to be able to tell which project a user's request to the registry is referring to (currently the registry API only provides the repository being referenced via the path parameters).

With this issue the aim is to expose the user's project path for the referenced user/repository by way of embedding the project path information in the user's JWT token.

This will unblock Grant "rename lease" on existing repositories t... (container-registry#960 - closed)

An example:

{
  "auth_type": "personal_access_token",
  "access": [
    {
      "type": "repository",
      "name": "jdrpereira/registry-test/foo",
      "actions": [
        "pull",
        "push"
      ],
      "meta": {
        "project_path": "jdrpereira/registry-test"
      }
    }
  ],
  "jti": "cf142f26-296c-4806-8bb0-2068d5f031da",
  "aud": "container_registry",
  "sub": "jdrpereira",
  "iss": "omnibus-gitlab-issuer",
  "iat": 1681301347,
  "nbf": 1681301342,
  "exp": 1681302247
}

Sidenote: I think we can use a root meta object to isolate any new metadata fields moving forward.

Then we could do a simple GET operation based on the project path. That would be as efficient as it can be.

Tasks

• When issuing registry JWT tokens embed the project path in the meta object

Other Notes

• A similar proposal exist for new fields (in #394965 (closed)) to aid in telemetry, so maybe we might want to establish a design that opens itself up to adding more fields