helm: tridentAutosupportImageTag not considered when `.Values.tridentAutosupportImage` is set

[hwo-wd]

Describe the bug
A clear and concise description of what the bug is.

Environment
Provide accurate information about the environment to help us reproduce the issue.

• Trident version: v25.02.1
• Trident installation flags used: trident-operator
• Container runtime: containerd v2
• Kubernetes version: v1.32
• Kubernetes orchestrator: Rancher v2.10.3
• Kubernetes enabled feature gates: n/a
• OS: Rocky Linux 9.5

To Reproduce
Apply the following yaml (I'm using fluxcd in this example, but it does not matter):

apiVersion: v1
kind: Namespace
metadata:
  name: trident
  labels:
    toolkit.fluxcd.io/tenant: sre-team
    pod-security.kubernetes.io/enforce: privileged
    pod-security.kubernetes.io/enforce-version: latest
    pod-security.kubernetes.io/warn: privileged
    pod-security.kubernetes.io/warn-version: latest
---
apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: trident-operator
  namespace: trident
spec:
  interval: 15m0s
  url: https://netapp.github.io/trident-helm-chart
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: trident
  namespace: trident
spec:
  interval: 15m0s
  chart:
    spec:
      # https://artifacthub.io/packages/helm/netapp-trident/trident-operator
      chart: trident-operator
      version: 100.2502.1
      sourceRef:
        kind: HelmRepository
        name: trident-operator
      interval: 15m0s
  values:
    tridentAutosupportImage: docker.io/netapp/trident-autosupport # one would use a custom docker hub proxy or therelike, but it illustrates the issue quite nicely

Note that I'm setting a custom tridentAutosupportImage, but no tridentAutosupportImageTag.
The trident-controller deployment does NOT come up though, due to the wrong latest tag used for this custom tridentAutosupportImage.

using this setup:

good (=w/o setting any custom values):

Expected behavior

container trident-autosupport in deployment/trident/controller uses tridentAutosupportImageTag:

{{ .Values.tridentAutosupportImageTag | default .Chart.AppVersion | trunc 5}} is respected

Fix is an easy one:
https://github1s.com/NetApp/trident/blob/master/helm/trident-operator/templates/_helpers.tpl#L116-L117

[hwo-wd]

I've just noticed, that the same applies to tridentImage and operatorImage: https://github1s.com/NetApp/trident/blob/master/helm/trident-operator/templates/_helpers.tpl#L190-L191, but these do NOT suffer from image pull errors due to the fact that there is a latest tag set and published.

Is there anything speaking against utilizing tridentImageTag/tridentAutosupportImageTag for tridentImage/tridentAutosupportImage?

• upside: no manual fiddling with helm tag values on upgrades, unless desired; I'd say that's arguably the more natural/expected way since every upgrade requires manually updating the image tags, too
• downside: this might break some people's helm deployments in case they are using the image as it's currently intended