How to categorize this issue?

/area ipcei
/kind enhancement

What would you like to be added:

If the MCM provider runs without a target cluster (--target-kubeconfig=none), it should report a new status field: Machine.status.addresses. The type is the same as Node.status.addresses.

If the driver returns {CreateMachine,InitializeMachine,GetMachineStatus}Response.NodeName, it should be added as an element with type=Hostname to the new status field, e.g.:

status:
  addresses:
  - type: Hostname
    address: shoot--foo--bar-worker-z1-77fd4-7tl93

{CreateMachine,InitializeMachine,GetMachineStatus}Response is extended with a new Addresses field so that the driver can return additional addresses as reported by the infrastructure API. All {CreateMachine,InitializeMachine,GetMachineStatus}Response.Addresses are merged into Machine.status.addresses.
With this, a driver can report all machine addresses, e.g., type=InternalIP or even type=ExternalIP where applicable.

Why is this needed:

With #994, MCM supports managing machines without a target cluster for the GEP-28 medium-touch scenario (gardener/gardener#2906).

To bootstrap the control plane machines, gardenadm bootstrap needs to connect to the machines via SSH to run commands and copy files.
For most cases, this will be done by creating a Bastion and proxying the node SSH connection over the bastion SSH connection.

Independent of whether a bastion connection or a direct connection to the machine (only possible with an external IP) is used, gardenadm needs to determine how to connect to the machine (i.e., the SSH target host).
Typically, a client (e.g., gardenctl ssh) would consult the Node.status.addresses field for this (ref).
However, there is no target cluster in gardenadm bootstrap – so no Node object.

By reporting Machine.status.addresses based on the infrastructure API, similar to what is reported in Node.status.addresses, MCM can support the gardenadm bootstrap use case.