Comment 24 for bug 1912844

To ensure that we understand the consequences of these changes, I've spent a bit of time tracking down everywhere this will affect in cloud-init by looking up the various call chains of `get_interfaces`:

Called by:
* `_get_current_rename_info`
  * `_rename_interfaces`
    * `apply_network_config_names`
      * `Distro.apply_network_config_names`
        * `Init._apply_netcfg_names`
          * `Init.apply_network_config`
* `get_ib_hwaddrs_by_interface`
  * `helpers.openstack.convert_net_json`
  * {`ConfigDrive`, `OpenStack`, `IBMCloud`}`.network_config`
* `get_interfaces_by_mac_on_linux`
  * `get_interfaces_by_mac`
    * `OpenNebulaNetwork` -- used to determine physical NICs for network config generation
    * Oracle -- a couple of ways in network config generation
    * EC2 -- network config conversion (theirs to ours)
    * `helpers.openstack.convert_net_json`
    * `helpers.digitalocean.convert_network_configuration`
    * `helpers.upcloud.convert_to_network_config_v1`
    * `net.get_devicelist` (but only on FreeBSD)
    * `find_fallback_nic_on_netbsd_or_openbsd`
    * `find_fallback_nic_on_freebsd`
    * `Networking.wait_for_physdevs`
      * `Init.apply_network_config`

Most of these are related to converting a network configuration format provided by a cloud into our own formats. None of this generation includes handling for creating OVS config (unsurprisingly!), so those cases should all be unaffected by changes to `get_interfaces` around OVS (except for a very minor performance hit for any new checks). Others are only used on *BSD, so we also don't need to worry about OVS interfaces there.

Every other call originates from `Init.apply_network_config`: this is the codepath that we are intending to affect, so we can see that there shouldn't be any unexpected consequences in other parts of the codebase.