Blocking project wide ssh keys while creating machine class

[rishabh-11]

How to categorize this PR?

/area control-plane
/kind enhancement
/platform gcp

What this PR does / why we need it:
In GCP, for each project, there is a project-wide ssh key which can be used to access all the VM instances in that project. Each Instance has an option to disable this by marking Block project-wide SSH keys as On from the GCP console. This PR adds a metadata field in the machine class spec during machine class creation, which will then be used by mcm-provider-gcp during VM instance creation to mark the Block project wide SSH keys field as On. The corresponding code in mcm-provider-gcp can be checked out here. The metadata field will be present in the providerSpec of machineclass and will look like this:

Which issue(s) this PR fixes:
Fixes #

Special notes for your reviewer:
The testing of this was done using a shooted seed local setup of gardener, and it worked as expected. The created machine had Block project wide SSH keys as On in the GCP console.

Release note:

`Block project wide SSH keys` will be `On` for all new machines created.

[gardener-robot]

@rishabh-11 Labels area/control, area/plane do not exist.

[dkistner]

Is there a concrete need already known to let users pass additional metadata for the machines?
If yes, we might wanna create an issue for it as it is better trackable?

[rishabh-11]

In the current mcm-provider-gcp code, we have a feature to add metadata field on a VM instance at the time of its creation(See this). But at the moment we cannot specify metadata field in the providerConfig section of the worker pool in the shoot yaml as the current extension-provider-gcp cannot decode it.(See this and this). So even though mcm provides the feature of specifying metadata on a VM instance, it will not be used as the machine class will never have this field present. This is the reason why I added this comment for now.

I am not opening an issue right now because we are unsure if we want to keep this field in the machine class. The reason is that any change in the providerConfig part of the worker section in the shoot yaml will generate a new machine class name (See this and this) and therefore a new machine class which will cause a rolling update of the machines. We don't want this just because some metadata field was changed. We already have an issue on mcm (See this) which requires something similar and should be sufficient to keep track of this as well.

cc @himanshu-kun

[dkistner]

/lgtm

[himanshu-kun]

/lgtm

[kon-angelo]

/lgtm