Merge Kubeconfigs when both integration methods are available for a cluster/project

Proposed release notes

Starting with GitLab 14.9, GitLab agent based connections are also available when deploying to environments that already have a certificate-based cluster. Previously, migrating from a certificate-based connection to an agent-based setup required extra steps and was especially difficult for group and instance-level clusters. By presetting both Kubernetes contexts, migration is largely simplified to selecting the context provided by the agent, instead of the default context, provided by the certificate-based connection.

Problem to solve

When a project has both a certificate-based cluster and an agent CI/CD tunnel shared with it, the KUBECONFIG only includes the certificate-based cluster's context. This makes it impossible to migrate projects under group-level clusters and instance-level clusters one-by-one to an agnent-based CI/CD workflow.

Proposal

Provide a merged KUBECONFIG that includes both the old certificate-based cluster and the agent contexts.

Background

Originally raised by @marshall007:

Also note that the legacy cluster integration appears to indiscriminately set the KUBECONFIG CI variable without checking to see if it has already been defined or attempting to merge them. I think it is important that you get a merged KUBECONFIG when both integrations are enabled so we can more easily migrate projects away from the legacy cluster integration.