Get rid of the clusterctl upgrade test fields exposed as environment variables

[furkatgofurov7]

What steps did you take and what happened?

Currently, clusterctl upgrade tests exposes multiple fields from ClusterctlUpgradeSpecInput as environment variable. Those env vars are only used by other infra providers and they can always read an env var in their _test.go file if they want to do that.

What did you expect to happen?

Not to expose the fields as env vars. Please see #8518 (comment) for more info

Cluster API version

main and supported release branches

Kubernetes version

No response

Anything else you would like to add?

No response

Label(s) to be applied

/kind bug
One or more /area label. See https://github.com/kubernetes-sigs/cluster-api/labels?q=area for the list of labels.

[furkatgofurov7]

/cc @sbueringer feel free to edit as much as needed if I missed something here, thanks!

[killianmuldoon]

/triage accepted

Sounds like a good cleanup - a good first step would be to scan the public CAPI-based provider e2e tests to see if any of these are being used as environmental variables today.

[sbueringer]

I think they are used today somewhere, but I think this shouldn't necessarily block us from removing them as there's an alternative (reading them in _test.go).

I just don't think it's sustainable for us to expose all "version-specific" fields as environment variables in addition to exposing them as fields. (also it's not ideal to have a Go API that additionally has env vars as an implicit API).

For example we recently added WorkloadKubernetesVersion which would also have to expose as env var to make it work. There might be more fields that we already have that we would have to expose to make the various permutations configurable via env vars (looking at our clusterctl upgrade _test.go)

[fabriziopandini]

/priority backlog

[fabriziopandini]

/assign @sbueringer