[SURE-10888] Mitigate Fleet CLI fetching the same Helm repo index multiple times

[aruiz14]

Is your feature request related to a problem?

#3742 introduced parallelism in the Fleet CLI.
However, when a fleet.yaml specifies helm repo, chart name and version, it will individually fetch the index from that repo and lookup the specified chart. This can become expensive on repositories with many entries.
Also, it's common for users of a private Helm repository to make all/most of their fleet.yaml point to the same repository, increasing the chances of repeatedly retrieving the same index.

Solution you'd like

Fleet CLI minimizes fetching the same index.yaml (for the same combination of URL and auth) for a single run.
There are techniques that allow aggregating concurrent code into a single call.
This solution is compatible with caching, which must be done carefully, in case the fleet controller also makes use of the code fetching this index.

Alternatives you've considered

Users can workaround this behaviour by:

• Using OCI chart registries instead of (legacy) Helm repositories.
• Use absolute download URLs in helm.chart to completely get rid of the lookup step.

Anything else?

No response

[aruiz14]

QA considerations

I think it's fine to test this for regressions only. I've tested it myself, since it's a little complex to setup:

• Prepared a git repository containing 26 bundles (from a to z).
  • Their helm.repo spec points to a local HTTP server, e.g. repo: http://192.168.1.2:8080:

helm:
  repo: http://192.168.1.2:8080
  chart: config-chart
  version: 0.1.0
  values:
    name: sample-cm-a
  takeOwnership: true

• Created a GitRepo like this:

apiVersion: fleet.cattle.io/v1alpha1
kind: GitRepo
metadata:
  name: test
  namespace: fleet-local
spec:
  repo: https://github.com/aruiz14/fleet-test-data.git
  branch: many-bundles-same-helm-repo
  correctDrift: {}
  paths:
  - many-bundles-same-repo

• Run a program locally, that serves an intentionally slow index.yaml and limited concurrency of 1: https://gist.github.com/aruiz14/39c37a3d8b3f768f2c169c2e774b139b
• Observe in the logs for the Fleet CLI job how the successful bundle creation message appear in batches:

...
time="2025-11-21T08:41:22Z" level=info msg="created (bundle): fleet-local/test-many-bundles-same-repo-test-d"
time="2025-11-21T08:41:22Z" level=info msg="created (bundle): fleet-local/test-many-bundles-same-repo-test-a"
time="2025-11-21T08:41:22Z" level=info msg="created (bundle): fleet-local/test-many-bundles-same-repo-test-c"
time="2025-11-21T08:41:22Z" level=info msg="created (bundle): fleet-local/test-many-bundles-same-repo-test-b"
time="2025-11-21T08:41:42Z" level=info msg="created (bundle): fleet-local/test-many-bundles-same-repo-test-h"
time="2025-11-21T08:41:42Z" level=info msg="created (bundle): fleet-local/test-many-bundles-same-repo-test-e"
time="2025-11-21T08:41:42Z" level=info msg="created (bundle): fleet-local/test-many-bundles-same-repo-test-g"
time="2025-11-21T08:41:42Z" level=info msg="created (bundle): fleet-local/test-many-bundles-same-repo-test-f"
time="2025-11-21T08:42:02Z" level=info msg="created (bundle): fleet-local/test-many-bundles-same-repo-test-i"
...