Allow Helm bin version to vary per Application beyond just v2 vs v3

[congiv]

Summary

It would be nice if the Helm binary version could vary per Application, similar to what is allowed for Kustomize.

Motivation

Recently we ran in to an issue when deploying Kong Ingress Controller to a variety of Kubernetes clusters. We were supporting k8s 1.22-1.24, and the Application synced successfully on target clusters on 1.23 or 1.24, but not 1.22.

The sync was failing because k8s 1.22 doesn't have HPA autoscaling/v2, even though the chart has logic to choose different apiVersions. Argo was able to successfully helm template the Application, and was choosing the correct --api-version flags which didn't include autoscaling/v2, but the manifest was still getting templated with autoscaling/v2.

We were running ArgoCD v2.6.7 at the time and the repo server had Helm v3.10.3 by default. Even though Helm 3.10 supports k8s 1.22, the version of the Go lib Helm was built with is aware of autoscaling/v2, so at helm template time Capabilities.APIVersions includes autoscaling/v2 by default. Changing to an older version of Helm where this isn't the case allowed the manifest to template correctly for the 1.22 cluster.

Passing --validate to helm template would also allow the manifest to be templated correctly, but since that would required API server access, we thought that allowing for multiple Helm versions would be the preferable option. Open to other suggestions as well!

Proposal

From the linked Application manifest in the declarative setup docs, It looks like .spec.source.helm.version only supports v2 or v3. If that field could either be extended to allow a full semver or add something different like .spec.source.helm.binVersion and we could specify in the argo-cm the paths to alternative Helm versions, that would be great.

[congiv]

For what it's worth, if this is accepted after triage I can work this. Thanks!