Make handing of floating pool (subnet) names more robust

[rfranzke]

How to categorize this issue?

/area robustness
/kind enhancement
/priority normal
/platform openstack
/exp intermediate
/topology garden seed

What would you like to be added:
Today it's possible to provide these data in the InfrastructureConfig:

      floatingPoolName: FloatingIP-foo-bar
      floatingPoolSubnetName: 744165f5-06dc-4fac-a9d9-3590d1f76f09

There is no validation to prevent submitting a GUID while a name is expected. Consequently, the infrastructure reconciliation (or deletion) will fail.
To improve this I'm seeing two options at the moment:

1. Improve validation code to forbid specifying a GUID when a name is expected
2. Improve infrastructure reconciliation to be capable to also work with GUIDs, i.e., dynamically determine (based on the input) whether to work with the name or with the GUID.

Personally, I'd prefer the second option.

Why is this needed:
Robustness, better user experience, less ops effort.

[dkistner]

Thanks for providing this. Makes sense from my point of view.
I think we can try the second option. Detecting a GUID should be easy. Maybe we should then also change the name of the to floatingPoolSubnet.

I guess this is not that urgent, right?

[rfranzke]

👍 Yes, it's not. Changing the name is difficult as it wouldn't be backwards compatible, but we can introduce floatingPoolSubnet and deprecate floatingPoolSubnetName and remove it after some months.