Add GraphQL query for the dependency proxy for packages settings

📞 Context

We're working on the very first version of the dependency proxy for packages. See #407460 (comment 1373731852) for all the details from the technical investigation.

At the core, the concept is right simple. GitLab will act with as a proxy. Basically, users can pull packages through it and GitLab will be a pull-through cache.

Package Manager clients (npm, maven, ...) <-> GitLab <-> External Package Registry

Because, GitLab is in the middle (aka proxy) of the package transport, we can leverage the GitLab Package registry to use it as a cache. In other words, before contacting the external package registry, we can check the local project registry to check if the package is already there. If that's the case, we can return it directly.

The first iteration will only cover the Maven package format.

We already added the API endpoints and logic in past MRs.

The dependency proxy is powered by some settings. Basically, users will need to set up the url and credentials of the remote registry. Have a look at the model class.

We now need the GraphQL changes to manipulate that settings object. See The dependency proxy settings GraphQL API (#410725 - closed). Basically:

1. Read the settings object from the project.
2. Update or create the settings object.

This MR solely focuses on (1.): the changes to read the settings object on GraphQL. (2.) will be implemented in a follow up.

This GraphQL parts will be used to power the frontend.

🛃 Permissions and gates

So obviously, not any user can read this settings object. So we will have a few checks to run before returning the object:

1. The packages feature needs to be enabled in the GitLab config (gitlab.yml). Enabled by default.
2. The dependency_proxy feature needs to be enabled in the GitLab config (gitlab.yml).
3. The packages feature in the project settings needs to be enabled.
4. This is an EE only feature, as such the project needs to have a license with the level of at least premium.
5. The user needs to be at least maintainer on the project.

To keep things a bit simple, all these checks have been embedded in the admin_dependency_proxy_packages_setting permission. If one of the above fail, the permission is not given.

🔮 Additional thoughts

The entire dependency proxy for packages is behind a feature flag so all the changes here are gated behind that feature flag. As such, we're going to follow https://docs.gitlab.com/ee/development/api_graphql_styleguide.html#feature-flags. In particular, all new GraphQL things will marked as alpha.

The settings object doesn't exist by default. We are using an approach similar to the other settings objects in the grouppackage registry. Please note that we don't have an id column on those settings objects, instead we have a project_id that is used as a primary key. As such, a project can only have one instance of those objects. The approach is as follows: when accessing the object from the project, either read it or build a default one (with empty or disabled values). As such, when all conditions are fulfilled (see above), the GraphQL query will never return a null object (even if the settings object doesn't exist in the database).

Lastly, I choose to not return the credentials back in the GraphQL. The idea is that we can only send them to create/update the settings object and then users will not have another chance to see them again. After all, they are credentials to an external package registry that can contain a pretty large amount of packages which is basically parts of software that can power an entire company. So, better be safe than sorry here.

🤔 What does this MR do and why?

• Update the EE ProjectType to read the dependency proxy for packages settings object.
• Add the GraphQL SettingType.
• Add the related specs.
• Add the related updates in the documentation.

The entire dependency proxy for packages is currently behind a feature flag. The rollout issue is [Feature flag] Enable packages_dependency_proxy... (#415218 - closed).

🖼 Screenshots or screen recordings

This is a GraphQL

⚙ How to set up and validate locally

1. Make sure that you have a license in the local instance.
2. In a rails console, enable the feature flag:

   Feature.enable(:packages_dependency_proxy_maven)

3. Open http://gdk.test:8000/-/graphql-explorer
4. Run the following query:

   query {
     project(fullPath: "<project full path>") {
       dependencyProxyPackagesSetting {
         enabled
         mavenExternalRegistryUrl
         mavenExternalRegistryUsername
       }
     }
   }

🏁 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.