Add admin section graphQL CI variables

Context

This work is in a series of MR to create a new application in CI/CD settings for variable. Before diving in, there are a few important point on both the structure of the MRs and the code itself.

MR	Link
Add Modal and dropdown component	!94238 (merged)
Add Table and Settings components	!94244 (merged)
Add Admin specific code	👈🏻 You are here
Add group specific code	!94385 (merged)
Add project specific code	!94388 (merged)

MRs structure

The total refactor was around 3k diff, which was too big. Therefore, we are going to ship smaller pieces like some refactored components and their tests in sequence. These components are not used anywhere unless the feature flag ci_variable_settings_graphql is enabled. To make sure that each little piece of application that gets merged with passing specs, we start by the smallest possible component and we move up to the larger application components all the way to the root where we fetch the new Apollo data.

At any point, please feel free to consult: !91710 (closed) for additional code context. That MR has all the changes we are aiming to have merged with this series f MR

The work

Note that all older components that use vuex have been prefixed with legacy_.

The ci_variable_settings, which used to be the root of the variable settings application, is used in 3 different pages:

• Project Variables: /$user/$Project/-/settings/ci_cd
• Group Variables /groups/$my_group_name/-/settings/ci_cd
• Admin Variables /admin/application_settings/ci_cd

Here are some key details on some small differences between each of them regarding environment scopes (which means, in which environment is that variable available):

• Project variables always have a possible list of environment scopes
• Group variable can have a list of environment scopes if the feature flag group_scoped_ci_variables is turned on (which it is by default)
• Admin variables can never have an environment scope

At the end of this chain of MR, we are going to have 3 top level components (one for each section) to use the right queries and mutations based on which page we are on. It also allow children components to simply get props and emit events and can be agnostic to where their data is coming from.

As for feature specs, they will be enabled in the very last MR.

What does this MR do and why?

This part adds the admin vue app and the resolvers for all sections. The reason why I am adding all of the resolvers now and not only the admin part is that I want to be able to look at the repetition that there is between some of the functions and address them in one go if it's required.

Screenshots or screen recordings

None for now

How to set up and validate locally

1. Enable the feature flag

Feature.enable(:ci_variable_settings_graphql)

1. Visit /admin/application_settings/ci_cd
2. Make sure you can add a variable
3. Make sure can edit a variable
4. Make sure that you can delete a variable
5. Make sure that any changes to variables is reflected in the table -->

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.