Setting DNS rewrote the connection profile and stopped there, so the
running device kept resolving through whatever it had before. Nothing
noticed while something else always activated the device afterwards: the
profile was written first and NetworkManager picked the resolvers up
when it got round to the interface on its own.
Turning a DHCP client off now applies the profile when the device is not
activated, which moved that activation ahead of the DNS write. A caller
that sets an address, disables DHCP, and then sets resolvers -- the
order a static configuration is naturally applied in -- ends with the
device activated on a profile that had no DNS in it yet, and the write
that follows never reaches the system. The profile carries the
resolvers, resolv.conf carries none, and ipv4.ignore-auto-dns has by
then ruled out the lease's resolvers as well: an interface holding an
address, a route, and no way to resolve a name.
Reapply the device after the change. Unlike turning a client off, this
risks nothing for a caller connected over the interface -- reapply
changes the device in place and does not tear the link down -- so it is
not conditioned on the device being unactivated, which is exactly the
case that needs it.
Bring an administratively down interface up in AddAddress before writing
its addresses and routes. The kernel installs an address's connected
route only while its link is up, so adding a gateway to a down interface
was rejected as unreachable. A link raised this way is part of the
pre-change state AddAddress restores, so it is returned to down on any
path that does not complete.
Also fix the rollback masking its own error: deleting the address it
added takes the default route with it, since that route resolved its
nexthop through the address's connected subnet. The following RouteDel
then answered ESRCH and was reported in place of "aborted operation due
to loss of internet".
