Decision: Separate configurations across two project integrations

📢 A decision has been made and is explained in #439036 (comment 1739158541)

Context

Related to Google Cloud and GitLab S3C Integration (&11412).

The related project began with Google Artifact Registry Integration for Contai... (&11443 - closed) as the main objective. Consequently, we initiated planning the implementation around a single project integration, named the Google Artifact Registry (GAR) project integration (#425066 (closed)).

However, as discussions evolved, it became apparent that some settings, specifically those related to Workload Identity Federation (WIF), would be necessary not only for Google Artifact Registry Integration for Contai... (&11443 - closed) but also for CI Workstream (&12111 - closed) and https://gitlab.com/groups/gitlab-org/-/epics/11890+.

An updated onboarding UX was later introduced (https://gitlab.com/groups/gitlab-org/-/epics/11890#note_1734560840), clarifying that two project integrations would be more effective:

1. Google Cloud IAM integration: This integration would act as the central point for all shared authentication-related configurations, which could be utilized across service-specific project integrations (like Artifact Registry) and other features (like Runner).
2. Google Artifact Registry integration: This would be a service-specific integration, reliant on the former, with only Artifact Registry specific configurations required.

Problem

• New Google Artifact Registry Project Integration (#425066 - closed) is in progress and is a prerequisite for the continued development of devopspackage. For engineers, the need for a separate IAM project integration emerged late in the process, leading to plans that revolved solely around the GAR project integration.

• Currently, there is no mechanism to enforce a relationship between two project integrations or to allow a "child" integration (e.g., GAR integration) to inherit certain attributes from a "parent" integration (e.g., IAM integration). Therefore, we cannot depend solely on the existing project integration framework, which implies additional development time.

• The IAM integration is under the realm of groupauthentication. As it does not exist yet and is a prerequisite for the GAR integration, this would block devopspackage and grouprunner saas.

Proposal

Our aim is to implement the UX presented in https://gitlab.com/groups/gitlab-org/-/epics/11890#note_1734560840 without causing short-term inter-team dependencies that could lead to a "deadlock".

Private Preview

• Proceed with a single project integration - the GAR one. This will involve allocating space for users to input (and for us to store) the WIF settings needed to interact with GAR. This approach is the current status of #425066 (closed) (awaiting merge).

• For Runner functionality, choose either to utilize the settings from the GAR integration (if active) or to record the WIF settings on the CI/CD configuration page as illustrated in the UX demonstration.

This approach results in WIF settings being duplicated (requiring users to input them twice, and a unified setup script needs to configure them in two places), but it prevents any team from being blocked.

Public Preview

• Enhance the project integration framework to allow for nested/related integrations.

• groupauthentication introduces a new parent IAM project integration, with WIF settings and IAM policies support.

• devopspackage updates the GAR integration to function as a child of the IAM integration, which must be activated first, and reuses the WIF settings from it (eliminating duplication).

• grouprunner saas modifies the CI/CD settings to reuse the WIF settings from the IAM integration, which also must be enabled beforehand.