bug: Respect provided kubeconfig in helm collector

[Danil-Grigorev]

Description, Motivation and Context

This change updates the Helm collector to properly use provided client configuration.

Previously, the collector used actionConfig.Init(nil, ...), which relied on implicit defaults and did not respect the configured cluster context. This resulted in using server https://localhost:8080 while performing operations on a host without KUBECONFIG or ~/.kube/config. In a scenario, when the support-bundle was used as a library, this resulted in a failed collection for helm.

To fix this, a new configGetter type was introduced that implements genericclioptions.RESTClientGetter. Helm collector now passes c.ClientConfig through.

Checklist

• New and existing tests pass locally with introduced changes.
• Tests for the changes have been added (for bug fixes / features).
• The commit message(s) are informative and highlight any breaking changes.
• Any documentation required has been added/updated. For changes to https://troubleshoot.sh/ create a PR here.

Does this PR introduce a breaking change?

• Yes
• No

[emosbaugh]

I am unclear if this function is used by the helm client. were you able to confirm either way? it may be possible to implement it like so.

Suggested change

	func (c configGetter) ToDiscoveryClient() (discovery.CachedDiscoveryInterface, error) {
	return nil, nil
	}
	func (c configGetter) ToDiscoveryClient() (discovery.CachedDiscoveryInterface, error) {
	discoveryClient, err := discovery.NewDiscoveryClientForConfig(c.restConfig)
	if err != nil {
	return nil, err
	}
	cached := memory.NewMemCacheClient(discoveryClient)
	return cached, nil
	}

[Danil-Grigorev]

I’ll check tomorrow, but from what I observed, only the implemented method was used. Helm operations there simply listed known resources, so it didn’t require discovery. Committed anyway, thanks for pointing that out.

[AmberAlston]

@Danil-Grigorev Making sure you saw the PR feedback above from @emosbaugh