Add cri and container_runtime to shoot_node_info

[voelzmo]

What this PR does / why we need it:
This adds information about the CRI worker pool configuration to shoot_node_info, looking like this

$ curl http://localhost:2719/metrics | grep garden_shoot_node_info

# HELP garden_shoot_node_info Information about the nodes in a Shoot.
# TYPE garden_shoot_node_info gauge
garden_shoot_node_info{container_runtimes="",cri="docker (default)",image="flatcar",name="marco-test-shoot",project="dev",version="2765.2.6",worker_group="fc-docker"} 0
garden_shoot_node_info{container_runtimes="gvisor",cri="containerd",image="flatcar",name="marco-test-shoot",project="dev",version="2765.2.6",worker_group="fc-contd-new"} 0

The following cases are considered:

• The node pool cri is configured explicitly with either .spec.provider.workers[].cri.name: docker or .spec.provider.workers[].cri.name: containerd. This value is directly put into the cri label
• The node pool cri is not configured explicitly and .spec.provider.workers[].cri: nil. In this case, we insert docker (default) in the label to distinguish from the explicit configuration option above. This can only be the case for k8s versions < 1.22 – afterwards a value of nil is defaulted to containerd.
• The list of container runtimes at .spec.provider.workers[].cri.containerruntimes[] can be nil or contain an arbitrary number of elements. The type field values will be concatenated with ", " and put into the container_runtimes label.

Which issue(s) this PR fixes:
related gardener/gardener#4110

Special notes for your reviewer:
We probably want a dashboard for this, just for convenience – I'm just not sure how to develop that, tbh.

Release note:

`shoot_node_info` contains two new labels: `cri`, containing the worker pool's cri configuration configured at `.spec.provider.workers[].cri.name` and `container_runtimes`, containing a comma-separated list of all supported runtimes configured at `.spec.provider.workers[].cri.containerruntimes[]`.

[istvanballok]

minor: I did a minor edit of the description.

[wyb1]

I'm not so sure about adding a list into a label value. I think it makes more sense to create a new timeseries for each container runtime. @istvanballok wdyt?

[istvanballok]

Based on the PR description:

container_runtimes is the (comma-separated) list of all supported runtimes

then I think it is fine to have the list in a single metric label, because the full list is the one that is supported. However, we should at least make sure that the sorting is consistent.

On the other hand, I'm not sure what the semantics of the supported runtimes really is - maybe it would be sufficient to expose only the used runtime?

[voelzmo]

Based on our call, I sorted the list of container runtimes to keep the order stable.

[wyb1]

Instead of using docker (default) here, can we just use (default)? If I understand correctly after k8s 1.22 the default will be containerd but the metric would still say docker (default) which is incorrect.

[voelzmo]

As discussed just now: Shoots with k8s >= 1.22 will always have a value for .spec.provider.workers[].cri.name. The defaulting logic we added with gardener/gardener#4222 takes care of the case where the user didn't specify anything.

[wyb1]

/lgtm

As discussed once there are more container_runtimes we can look into this again and possibly create a new metric to prevent adding a list into a label.