Comment 2 for bug 1577844

Turns out this was all just an illusion. ifup@.service already has "After=network-pre.target", i. e. is actual execution will already be deferred until after network-pre.target. cloud-init-local.service is Before=network-pre.target, so the effect of any hotplug event will sort correctly.

I added a "ExecStart=/bin/sleep 5" to cloud-init-local.service, and this shows that network-pre.target and ifup@ correctly blocks:

May 04 14:57:05 autopkgtest cloud-init[336]: [CLOUDINIT] stages.py[INFO]: network config is disabled by /var/lib/cloud/data/upgraded-network
May 04 14:57:05 autopkgtest cloud-init[336]: Cloud-init v. 0.7.7 running 'init-local' at Wed, 04 May 2016 12:57:04 +0000. Up 3.64 seconds.
May 04 14:57:10 autopkgtest systemd[1]: Started Initial cloud-init job (pre-networking).
May 04 14:57:10 autopkgtest systemd[1]: Reached target Network (Pre).
May 04 14:57:10 autopkgtest systemd[1]: Starting Raise network interfaces...
May 04 14:57:11 autopkgtest systemd[1]: Started ifup for ens3.

So there is nothing to fix in ifupdown, and it should be safe to drop all the hackery in cloud-init: /run/cloud-init/network-config-ready from cloud-init-local.service, the whole cloud-init-wait, and /lib/udev/rules.d/79-cloud-init-net-wait.rules.