Upgrade Helm to v4.0.4

[matheuscscp]

Part of: fluxcd/helm-controller#1300

[matheuscscp]

I have tested this:

• In a cluster with 18 HelmReleases from OCIRepository charts.
• With a simple HelmRelease that has .spec.chart pointing to a GitRepository.
• With a HelmRelease for kube-prometheus-stack OCI chart version 69.8.2 vendored into a GitRepository (also using .spec.chart). In this case all the subcharts were also vendored into the GitRepository.
• With a HelmRelease for kube-prometheus-stack using the upstream HTTPS repo, chart version 80.13.2.
• With a HelmRelease for kube-prometheus-stack vendored into a GitRepository from the upstream Git repository. In this case the subcharts were pulled by source-controller.

I will still test this with a HelmRepository type oci and TLS.

[matheuscscp]

Turns out that the login-touches-disk semantics still exists in Helm 4. The only difference is that an empty file now errors out. In Helm 3.19 they fixed this error (for backwards compatibility) by writing a {} file themselves. Helm 4 .Login() still stores the credentials, and expects the file not to be empty, it must have at least {} inside (so the oras-v2 JSON parsing does not error out).

The good news is that the only operation we actually use from Helm's OCI client is .Tags(), and this operation only needs an authorizer to be set, which can be done through the ClientOptAuthorizer() API! So our best course of action here is to remove login semantics altogether and just use this API.

I will update the PR after these facts.

[matheuscscp]

I will still test this with a HelmRepository type oci and TLS.

We now have two tests that prove this is working:

• HTTPS With CA cert and client cert auth
• HTTPS With CA cert and client cert auth, invalid key

[stefanprodan]

LGTM

Thanks @matheuscscp 🥇