dnssec-trigger-script should honor NetworkManager rc-manager behavior

Problem Overview

When dnssec-trigger-script --cleanup runs on service shutdown and it detects the system using NetworkManager, it will always create a symlink /etc/resolv.conf -> /var/run/NetworkManager/resolv.conf, regardless of the NetworkManager rc-manager setting. Neither the behavior nor target paths are configurable.

While this shortcut works since the rc-manager=file handler will effectively switch to rc-manager=symlink if it encounters a symlink ...

file: NetworkManager will write /etc/resolv.conf as file. If it finds a symlink, it will follow the symlink and update the target instead

It breaks dns resolution within rootless containers for users who depend on non-public dns servers (ie. enterprises) as set in their resolv.conf. This is due to the fact that the symlink is created under /var/run and slirp4netns --enable-sandbox ... as launched by podman will not follow symlinks outside of /etc or /run.

From slirp4netns.1.md

--enable-sandbox (since v0.4.0) enter the user namespace and create a new mount namespace where only /etc and /run are mounted from the host.

Requires /etc/resolv.conf not to be a symlink to a file outside /etc and /run.

It's also an unexpected change to the system -- the script should aim to restore the system as best it can to the pre-launch state

Proposed Solution

1. Honor rc-manager and assume file unless symlink is specified, and copy/symlink as appropriate.
2. Provide options to control this behavior directly in dnssec-trigger-script
3. Provide options to change the target symlink value

Workaround

Users affected by this issue can workaround it by removing the symlink after dnssec-trigger-script --cleanup has run and copy the file back into place OR symlink to /run/NetworkManager/resolv.conf instead.

$ rm -f /etc/resolv.conf; cp /var/run/NetworkManager/resolv.conf /etc/resolv.conf;
$ rm -f /etc/resolv.conf; ln -s /run/NetworkManager/resolv.conf /etc/resolv.conf