These files are dynamically generated by udev rule for any ethernet
interface other than lo or ifbs, but we don't want them to pay attention
to any interface if we've already found the control net device.

Unfortunately, I didn't notice the first time, but the include causing
all the problems was an apparently unnecessary math.h.  Simply removing
it fixed all the odd libstdc++ errors; trying to fix them all up and
leaving it in was much more complicated.  This works on gccs 4, 6, 7, 8.

This is a good outcome because the iperf-2.0.10 patch is still subtly
wrong in some important way; bandwidths are inconsistent or sometimes
consistently asymmetric (with no good reason).  So some parameter must
still not be being exchanged between client and server.

/etc/init.d/ntp was being run twice on Ubuntu14 (and was failing slowly
the first time) because of the presence of
/etc/network/if-up.d/ntpdate... which would run ntpdate then
/etc/init.d/ntp via invoke-rc.d... so we would see a double start with
lots of delay.

So now we overwrite that hook script!  Ugh.

(Also fix a few bogus stderr redirects.)

(These days, the 8021q module has deps.)

This would've resulted in legit delay not being set.  I don't really
know when this behavior changed, but must be quite recent.  Anyway, now
we just don't supply the drop param unless we actually have a plr/rplr.

(This is just about getting rid of spurious errors; of course we haven't
been trying to reboot into custom kernels for a long time.)

Allowing vnode experiments running on shared nodes to share IPv4 subnets
is a natural thing in Emulab; not so in Docker.  This is the Emulab side
of that fix.

The Docker side relies on modifications to Docker (see
https://gitlab.flux.utah.edu/emulab/moby/commits/emulab) to add a real
Layer 2 mode to the bridge and macvlan drivers, so that Docker doesn't
require IPv4 configuration of the bridge; and so that it allows Layer
2-only bridges to have overlapping IP subnets.  Normally it does not
allow the latter because it expects that any network might be
routable/reachable by any other network.

USER is picked as the user specified by the Docker config
or if that is empty is defaulted to root. If the USER is root
then HOME is defaulted to /root otherwise it is set to the
HOME found when running `env` in a sample of the container.

PATH is set to a normal sane default.

Any of these environment variables can be overridden in the
Dockerfile or using profile parameters at any time. This is
just to help users who rely on Docker providing defaults.

Especially libvnode_docker::analyzeImageWithBusyboxCommand, which runs
the busybox-static binary from the root context in the container with
the given command (and extra container run API configuration).

(Instead of only supporting an image from an external repo as the base.)

is off, this is just the control net interface (xenbr0). But when
XENVIFROUTING is on, we want to listen on the control net bridge plus
all of the container vifs. Since these are not created until the
container is started, we have to call restartDHCP from emulab-cnet (we
were already doing that), and now we also call reconfigDHCP() when the
contain is destroyed so that interface list is correct (note that DHCPD
does not seem to care if an interface dissappears, or even if an
interface does not exist when starting.

The main point here, is that on shared nodes we have to restrict the
number of interfaces that DHCPd listens on (or even looks at) since it
can be 100s, and dhcpd was taking well over a minute to start up each
time.

Aside; minor change to not look at the IP config for bridges, just the
mac. Takes to long when there are 100s of bridges.

rewrite the interface list in /etc/defaults/isc-dhcp-server. We do
not need to restart DHCP, it does not mind that the vif is gone.

since the vif foes not exist yet, and we call restartDHCP() again in
emulab-cnet after the container and vif exist. In fact, no point in
restarting DHCP when removing an entry, since by that time the vif is
gone and dhcpd does not seem to mind that anyway.

little file!

Also fixed a small build bug for < 1.1.0.

(We cannot ignore interfaces without an IP; that was the critical new
problem.)

Sometimes there seemed to be a race where systemd-networkd would start
trying to find .network config files before the emulab control net udev
rules (the shell script the rule launches, rather) could actually write
them.  This race would sometimes manifest, but mostly not.

By default, systemd-networkd does not wait for udev to finish
processing its device events.  This seems odd, but I guess it is not
expecting dynamic configuration in /run/systemd/network like we use
(although its docs explicitly allow for this case).  Oh well.  `udevadm
settle` is supposed to indicate that udev is done processing all device
events; but it must not mean that it is finished processing all the
rules!  So not only do we wait for it to settle; we wait for the
appearance of at least one .network file (that we wrote, hopefully) in
/run/systemd/network .  No one else would ever write them there,
clearly.

(Somehow we've gotten away without doing this on Linux vhost images, but
that day is done.  We need to attempt safe shutdown of vnodes just in
case.  I suspect there is some risk that this could run afoul of systemd
service timeouts if there are many vnodes, but we'll see.)