Wait for interface link ready before starting udhcpc

[Ihar Hrachyshka]

(This is somewhat related to https://bugs.launchpad.net/cirros/+bug/1273159 though I think it's a separate bug, even if its exacerbated by the bug I linked to.)

The issue that when cirros boots, it ups the interface, then immediately starts udhcpc. In some environments, the interface may not establish link quick enough, and so DHCP requests sent by udhcpc are lost.

The slowdown of interface link bring up may have different sources (general slowliness of the kernel could be one), but in my particular scenario it takes 2 seconds for the kernel to bring up the link for eth0 when I use 'e1000' interface model type in libvirt definition for the machine that runs cirros image. If I switch to 'virtio' interface model type, it doesn't take that long to set up the link, and the first DHCP request reaches the DHCP server.

While one could argue that cirros should be executed with virtio and not e1000, it may not be the default (or even possible) in some scenarios. For example, kubevirt (VMs for kubernetes) doesn't currently allow to pick interface model type, using e1000 for all machines, which slows cirros boot by 1 minute.

I think the right thing to do here is:

0. Document e1000 behavior somewhere (not sure if the project has documentation; I for one couldn't find it).
1. Wait until the link is ready.
2. (To mitigate any other sources of frame drop) Become more aggressive in issuing DHCP request. (This is the exact topic for https://bugs.launchpad.net/cirros/+bug/1273159)

[Ihar Hrachyshka (ihar-hrachyshka)]

For the record, kubevirt issue that revealed the problem is: https://github.com/kubevirt/kubevirt/issues/936