Ambiguous underlay network handling with `microcloud add`

[masnax]

When setting up a cluster with microcloud init, and setting up OVN, we ask if the user wants to set up underlay networking. MicroOVN accepts configuration for each system over its API and applies it when initializing the system.

During microcloud add (and microcloud service add), we again offer the user to set up underlay networking, but which systems to set the networking up on cannot be easily determined.

Ideally, if the user previously did not configure underlay networking, we should let them configure it now that they are adding new systems. But that involves both fetching the existing configuration and applying it over the API on a running system.

MicroOVN does not have API support to fetch the existing underlay configuration, nor does it support setting the underlay configuration over the API after bootstrap/join.

We can't even really be conservative and only allow setting up new systems because if the user previously skipped setup, then not all systems will have an underlay network set.

So there's 2 parts to this:

• We need a way to get the current underlay network configuration for the cluster. If we only have this, then we can check the existing cluster configuration and only present a table if a configuration exists. This table would be limited to just the new systems. This means we wouldn't be able to introduce underlay networking if it was not set up before running microcloud add.

• Also add a way to set the underlay network configuration of existing systems. With this, we can inspect old systems and include them in the configuration if underlay networking was initially skipped. This is the same behaviour as storage pool, osd, and uplink network configuration.

LXD-1443

[masnax]

As discussed, the proposed solution will look sort of like this:

• Query MicroOVN (using https://github.com/ovn-org/libovsdb) to get the current Encap IPs of all cluster members.
• Check if the existing Encap IPs fit within the corresponding subnet on one of the interfaces of local system.
• The user selects the Encap IPs of new cluster members.
  • If the "new node" has selected an IP that does not fit within the above subnet, present a warning. The user must choose to proceed anyway, or retry selecting an interface.
  • If a subnet could not be found at all (because the existing nodes' Encap IPs are already not in the same subnet), present a warning. The user must choose to proceed anyway, or exit the setup.