Support any bootstrap provider with MachinePools

[anmazzotti]

What type of PR is this?

/kind feature

What this PR does / why we need it:

This patch makes the AzureMachinePool controller (Bootstrap)Config agnostic.

Instead watching KubeadmConfigs (or any other custom config added via bootstrap-config-gvk argument), the controller is now watching any bootstrap secret directly, bypassing the config layer.
As per bootstrap contract, the watch logic works in the following way:

1. Only watch cluster.x-k8s.io/cluster-name labeled Secrets
2. Retrieve the (Bootstrap)Config name and kind from the first controller owner reference on the bootstrap Secret
3. (This step was not changed by this PR) Assume the (Bootstrap)Config name has the same name of its related MachinePool to enqueue an also related AzureMachinePool reconcile.

Note that since we are not watching KubeadmConfigs directly, the related RBAC permission was also cleaned up.
Since we don't actually trying to fetch any (Bootstrap)Config, there is no need for further RBAC settings when using other Bootstrap providers.

This should now also work in case of users providing their bootstrap Secret manually, assigning a custom DataSecretName in their (Bootstrap)Config. Still assuming they respect the contract linked above when creating the custom Secret.

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes rancher/highlander#100

Special notes for your reviewer:

TODOs:

• squashed commits
• includes documentation
• adds unit tests
• cherry-pick candidate

Release note:

action required
The `bootstrap-config-gvk` controller argument has been deprecated. The controller is now able to work with all [bootstrap providers](https://cluster-api.sigs.k8s.io/reference/providers#bootstrap).  
Users managing their own bootstrap Secrets, by configuring the `Machine.spec.bootstrap.dataSecretName` manually, are expected to respect the [bootstrap secret contract](https://cluster-api.sigs.k8s.io/developer/providers/contracts/bootstrap-config#bootstrapconfig-data-secret).

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: anmazzotti / name: Andrea Mazzotti (1660865)

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign nawazkh for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[k8s-ci-robot]

Welcome @anmazzotti!

It looks like this is your first PR to kubernetes-sigs/cluster-api-provider-azure 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/cluster-api-provider-azure has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @anmazzotti. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

[alexander-demicev]

/ok-to-test

[alexander-demicev]

is flag removal considered a breaking change?

[anmazzotti]

Good question. I think it is, but on the other hand this is still experimental and I doubt anyone is using it at the moment.

If we want to be extra safe I can simply keep it and just print an error(?) message informing the user it's deprecated.

[anmazzotti]

/retest

[k8s-ci-robot]

@anmazzotti: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-cluster-api-provider-azure-e2e-aks	1660865	link	true	/test pull-cluster-api-provider-azure-e2e-aks

Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.

[anmazzotti]

Switching the PR back to Draft as we just discussed in the CAPI community meeting a cleaner approach with dynamic watches.

[anmazzotti]

Closing this PR in favor of a better approach: #5416