Code review comment for ~raharper/cloud-init:fix/lp-1766287-run-after-udev-settle-service

In the case where networking is disabled in cloud-init and the cloud has their own; the race still exists; that is if the network names don't match the configuration in the image when the networking is applied; it will fail.

There are no APIs that I'm aware of that tell you if an interface has been processed by udev;
The kernel will report the name_assign_type = 4 if userspace has applied a rename;

The blocking trigger is interesting, however, the race in this case is that an existing net subsystem trigger has already run (systemd-udev-trigger.service); so it seems wrong to trigger the net subsystem *again* after it's already applying any rules and the uevents are in-flight.

While it's interesting that ifindex don't change, none of our network configuration formats (eni, sysconfig, netplan) accept config by ifindex, so that won't help us.

We certainly don't want to add time to boot just because; I think there is a strong argument that we want cloud-init-local to run at a time when any udev rules which could rename interfaces has been applied. I'm open to alternatives, but systemd-udev-settle.service certainly seems very useful way to ensure this state.