Add GraphQL mutation 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. This was implemented in Add GraphQL query for the dependency proxy for ... (!132877 - merged).
2. Update or create the settings object. 👈 This is this MR.

This MR will solely focus on the GraphQL mutation.

The issue for GraphQL changes is The dependency proxy settings GraphQL API (#410725 - closed).

Last thing to know here is that this feature (the dependency proxy for packages) is a GitLab Premium only feature. So the files will live on the EE side only.

🛃 Permissions and gates

So obviously, not any user can update 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 (in the previous MR: Add GraphQL query for the dependency proxy for ... (!132877 - merged)). If one of the above fail, the permission is not given.

This allows us for the mutation here to simply check for the admin_dependency_proxy_packages_setting permissions and that's it.

🔮 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 trying to update the settings with the mutation, we're going to either create a new settings object or update the existing one.

Lastly, I choose to not return the password back in the GraphQL. The idea is that we can only set it to create/update the settings object and then users will not have another chance to see them again. After all, they are passwords 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?

• add a GraphQL mutation to create or update the dependency proxy (for packages) settings.
• add the related service to create or update the settings.
• add the related specs.
• add the related documentation.

The entire dependency proxy for packages is behind a feature flag. The rollout issue is: #415218 (closed). Currently not enabled anywhere.

🖼 Screenshots or screen recordings

None

⚙ 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:

   mutation {
     updateDependencyProxyPackagesSettings(input: { projectPath: "<project full path>", enabled: true, mavenExternalRegistryUrl: "https://test.dev", mavenExternalRegistryUsername: "u1", mavenExternalRegistryPassword: "p1"}) {
       dependencyProxyPackagesSetting {
         enabled
         mavenExternalRegistryUrl
         mavenExternalRegistryUsername
       }
       errors
     }
   }

5. (optional) You can read back the settings query with the GraphQL query:

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

Additionally, you can try:

• disabling the feature flag.
• disable the dependency_proxy or the packages in the config gitlab.yml.
• disable the packages feature in the project settings.

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

💽 Database analysis

• create or update the settings object.