rkt now provides /etc/resolv.conf in each app's chroot if it does not
exist. If the ACI provides such a file, rkt does not touch it.

The "nameserver" entries come from two sources:
1. as a comma-separated list from the command line (--dns=xx.xx.xx.xx)
2. from the selected network (--net=...)

If the 'host' network is requested, it copies /etc/resolv.conf from the
host. If another network is requested, it gets the name servers from the CNI
plugins.

Implementation detail: systemd-nspawn can overwrite /etc/resolv.conf. It
is supposed to overwrite it only when the container uses the host
network namespace.  However, the container network namespace is created
by rkt via CNI and not by systemd-nspawn, so systemd-nspawn is not aware
of the network configuration. As a consequence, we cannot use stage1's
/etc/resolv.conf. Instead, rkt write /etc/rkt-resolv.conf in stage1 and
prepare-app bind-mounts it in stage2's /etc/resolv.conf.

It works in this way:

> $ cat /etc/rkt/net.d/alban.conf
> {
> 	"name": "alban",
> 	"type": "ptp",
> 	"ipMasq": true,
> 	"ipam": {
> 		"type": "host-local",
> 		"subnet": "172.16.42.0/24",
> 		"routes": [
> 			{ "dst": "0.0.0.0/0" }
> 		]
> 	},
> 	"dns": [
> 		"8.8.4.4",
> 		"12.12.12.12"
> 	]
> }
>
> $ sudo rkt run --net=alban --dns=1.1.1.1,2.2.2.2 \
> 		sha512-a2fb8f390702 --interactive
> / # cat /etc/resolv.conf
> # Generated by rkt
>
> # Name servers passed on the command line
> nameserver 1.1.1.1
> nameserver 2.2.2.2
>
> # Name servers from CNI
> nameserver 8.8.4.4
> nameserver 12.12.12.12
> / #