interfaces: T3871: give a re-created Hyper-V NIC the name of the NIC it replaced

A Hyper-V NIC is known by its MAC alone. One deleted and created again on
the same VM - an Azure NIC re-created, or a Hyper-V adapter removed and
added - comes back with a new MAC, so nothing on it matched the store: its
name stayed reserved, the new NIC got a new name, and its configuration
was left on a name with no NIC. cloud-init does not run again on the same
instance, so nothing else repairs it.

At boot, a vacant name now goes to a new NIC only when the pairing is not
in doubt:
- exactly one recorded name has no NIC, and exactly one new Hyper-V NIC
  appeared. With more of either, the order the NICs come up in does not
  say which replaced which, so nothing is handed over and the names stay
  reserved, as before;
- the name went missing at this pass. The store records which names were
  missing at the last pass, so a NIC removed for good does not hand its
  name to a NIC added at a later boot;
- the name's own NIC was a Hyper-V one. The store records which names sat
  on a Hyper-V NIC; a MAC-keyed name can belong to other hardware, and a
  store written before this was recorded hands nothing over (the boot pass
  logs that when it holds a name back);
- only at boot. On a running system the configuration under a name is not
  applied to the NIC that takes it, so the hotplug unit passes --hotplug,
  which names the new NIC like any other and records the vacant name as
  missing, so the next boot does not hand it over either.

An adoption is logged as a warning, reported under 'adopted' in the status
file (kept there across hotplug passes while it holds), and repeated by
vyos-router, as a slot match is: verify the port before relying on its
configuration.

0 files changed, 0 insertions, 0 deletions