Previously, stopping [email protected] would delete the
installed configuration for the foo interface and trigger a networkd
configuration reload.  Doing so would revert the interface's
configuration back to the default, and the subsequent networkd reload
would reset any conntrack state for connections associated with that
interface.  Doing so would cause traffic for any connections that
relied on the RELATED or ESTABLISHED conntrack properties to be
dropped, when the expectation is that it would continue to be passed.

Impact from this issue was particularly visible on systems running
Docker in bridged networking mode, where the containers rely on the
Docker-installed iptables rules for connectivity, including an ACCEPT
rule based on established connections, by default.  In this case, any
connections open from local containers to a remove service would see
100% packet loss after stopping [email protected] (where foo
is the interface through which container generated traffic would
egress).

With this change, the generated config is left behind after stopping
the [email protected], even after an ENI is removed.  In
practice, this is not a problem because:

1. re-attaching the same ENI will use the old configuration, with any
configuration changes picked up by the policy-routes service
3. Connecting a different ENI in the same slot (thus with the same
name) will not match the MAC Address value, and will use the default
configuration.  The policy-routes service will then generate the
correct ENI-specific configuration, overwriting any existing
configuration left behind by the previously attached ENI.

The systemd default of of `control-group` for this value is more
aggressive than we want.

...rather than explicitly in the udev rules.