Helm Chart: improve inconsistent versioning

[Obirah]

When installing the Operator (v2) via Helm and using renovate to keep it up-to-date, the inconsistent versioning between Releases and the Charts files makes the configuration of renovate unnecessarily complicated:

Release are tagged with a v prefix: https://github.com/Azure/azure-service-operator/releases/tag/v2.18.0
Chart archives don't have the v prefix: https://github.com/Azure/azure-service-operator/blob/main/v2/charts/azure-service-operator-2.18.0.tgz

As the charts are not published to a Helm registry but are stored in the repository, we can't simply use the helm datasource for our renovate configuration and are reliant on the versions being consistent.

[matthchr]

We had an issue in the past where users complained about the v prefix on the Helm chart versions because it isn't semver compliant.

Maybe the solution here is for us to just move the chart to a registry. It something we've talked about before (in #4798) and even had an issue tracking it in the ASOv1 days (#991), but at that time we closed it because the tooling wasn't quite there (at least for ACR). I think now it is.

Can you confirm, if the Helm chart were hosted in ACR/MCR or GitHub registries, this wouldn't be an issue for you?

[Obirah]

Yes, I can definitely confirm that. We worked around it by creating a virtual Helm repository in our Artifactory that points to the sub-directory in your git repository. We have generic remotes for ACR, MCR, GHCR and so on in our Artifactory anyway, so that would reduce the need to maintain a highly specific virtual repository that is only relevant to a fraction of our company.