Drop fix RBAC from component management in clusterctl

[fabriziopandini]

clusterctl dropped support for many instances of the same providers a couple of release ago, but there are still some part of the code that consider this uses case. By cleaning them up we can simplify the codebase.

One of them is fixRBAC while processing components.

The change is pretty simple (drop the func and corresponding tests), but the author of this PR should take care of doing some manual testing on init and upgrade from an older version of clusterctl

/area clusterctl /kind cleanup

[sbueringer]

/triage accepted

[oscr]

Some control questions to get the scope right from the start:

• What clusterctl version(s) would be reasonable to upgrade from?
• Should we test step by step upgrade (1.0 -> 1.1 -> 1.2 -> master) and/or "jump" upgrades (1.0 -> master, 1.1 -> master)?
• Would creating a cluster (the getting started guide with capd) and then upgrading the cluster be a sufficient test scope?

[oscr]

/assign

[fabriziopandini]

What clusterctl version(s) would be reasonable to upgrade from?

I will test upgrading from v1.2.2 (latest release with fixed RBAC) to main

Should we test step by step upgrade (1.0 -> 1.1 -> 1.2 -> master) and/or "jump" upgrades (1.0 -> master, 1.1 -> master)?

I don't think it is necessary to test sequences, once we move from a version with fixed RBAC to the new version without RABC fix, all the combination should be the same

Would creating a cluster (the getting started guide with capd) and then upgrading the cluster be a sufficient test scope?

Yes this (while looking at RBAC rules in the cluster) or the E2E for clusterctl upgrades

[sbueringer]

Sounds like running e2e-full on the PR should cover it (and more)

[fabriziopandini]

Yes, E2E covers it, but human eyes have to check the we are not leaving behind objects when we move from a version with fixed RBAC to the new version without RABC fix

[chrischdi]

/retitle Drop fix RBAC from component management in clusterctl