Use Helm 3 for GitLab-managed apps in new clusters [RUN AS-IF-FOSS]

What does this MR do?

This is the first stage of a migration to Helm 3 for GitLab managed apps (see #120021 (closed)), where we use Helm 3 by default unless the cluster is already using Helm 2.

To do this, we split Gitlab::Kubernetes::Helm::*Command into two modules:

• V2: The old classes, copied verbatim, wrapped in a V2 module
• V3: A port of the relevant V2 classes over to V3 (not all of them are relevant for Helm 3)

The V2 and V3 commands implement the same interface for the Kubernetes pod generator, Gitlab::Kubernetes::Helm::Pod, so each module's BaseCommand also gets a new #helm_version method, replacing the previous Gitlab::Kubernetes::Helm::HELM_VERSION constant, as well as a #env method for command version-specific environment variables (currently only TILLER_NAMESPACE).

We then use a newly added helm_major_version column on Clusters::Cluster to decide the command module to use when interacting with apps.

Todo

• Separate Helm 2 and Helm 3 command classes and tests
• Make Helm command pod retrieve the helm version from the command class
• Add helm_major_version to the cluster level
• Resolve each app record's underlying helm command based on the cluster's major version
• Add and update tests

Manual QA

Replaces screenshots, because this is entirely on the backend.

Methodology

For Helm 2 and Helm 3:

1. Attach a local Kubernetes cluster to GDK (3-node k3d cluster)
2. Test installation with charts: Ingress, Cert-Manager, Prometheus, Runner, Elastic Stack
3. Test uninstallation with the same charts
4. Install Prometheus and test that changing alerts creates a new release with the alerts file updated

Results

• Helm 2:
  • Install
  • Uninstall
  • Prometheus alert updates (PatchCommand)
• Helm 3:
  • Install
  • Uninstall
  • Prometheus alert updates (PatchCommand)

Does this MR meet the acceptance criteria?

Conformity

• Changelog entry
• Documentation (if required)
• Code review guidelines
• Merge request performance guidelines
• Style guides
• Database guides
• [-] Separation of EE specific content

Availability and Testing

• Review and add/update tests for this feature/bug. Consider all test levels. See the Test Planning Process.
• [-] Tested in all supported browsers
• [-] Informed Infrastructure department of a default or new setting change, if applicable per definition of done

Security

If this MR contains changes to processing or storing of credentials or tokens, authorization and authentication methods and other items described in the security review guidelines:

• [-] Label as security and @ mention @gitlab-com/gl-security/appsec
• [-] The MR includes necessary changes to maintain consistency between UI, API, email, or other methods
• [-] Security reports checked/validated by a reviewer from the AppSec team