* Rename d/resolvconf to d/resolvconf-forwards, to make it more
  explicit we're adding forwarders to unbound not pushing unbound
  as a nameserver

* Add comments to this file (which is installed as
  /etc/resolvconf/update.d/unbound) describing what it is
  for and how it is used.

* Add an alternative way to turn this hook off  by specifying
  USE_RESOLVCONF_FORWARDS=false in /etc/default/unbound.

* Do not rely on the presence of  unbound-control keys/certs,
  since unbound-control can work over unix-domain socket too.

* Do not hide possible error messages produced by unbound-control
  since this makes debugging difficult.

* Other less visible changes and cleanups.

* Install it with execute permissions (0755 instead of 0644) -
  this will enable this script for new installs, but will keep
  it disabled for old installs

There's almost no common parts left between the old file and
the new file.

We should not automatically start the unbound-resolvconf.service helper
service, it is (re)started as part of the main unbound.service.
In debhelper compat level >= 10 the startup is done automatically.

change other two functions in there to be a bit safer wrt input
handling and a bit easier to read, especially the innner "if"
in do_resolvconf_start (and add a comment there).

Thanks to Simon Deziel for the ideas and his initial work here.

It is usually bad to remove a system user.
Some people add system users manually before installing a package to
maintain the same uid/gid values across different machines.
A package remove/purge does not guarantee all files owned by this user
are removed, by removing the user these files become orphan and on next
package install this uid can be reused for something else creating havoc.

See also #228692

There's no actual need for the daemon to touch the pid file
except of writing it.  Multiple instances of the daemon
(with the same config) are not possible because we can not
open the same network ports, second instance will fail to
start, - this makes whole pid file checking unnecessary.

But the idea of giving an unprivileged user ownership of
the pid file is inherently wrong, since it is not expected
for a pid file to have any "interesting" contents (which
can create a compromised unprivileged user).

There's no need to chown the control socket to the unpriv user,
only group membershi actually matter.  But making the socket
owned by the user feels wrong.

This makes unbound.conf to be the same as before all
remote-control changes

Move (append) content of d/NEWS to d/unbound.NEWS, because
all entries in d/NEWS were about the daemon only, not about
*all* binary packages.

Reformat the 1.15.0-2 entry to use the correct identation.

Move the remote-control section above the include directive
so it is possible to override it there, and fix comment

Move dns-root-data from Depends to Recommends.
Nothing is changed for most users (apt installs
Recommends by default). Once unbound is first run
with dns-root-data installed, it is possible to
uninstall it, as unbound will use RFC 5011 trust
anchor tracking to keep this file up to date.

Since the default control-enable is now off as per upstream,
generating the ssl keys is not strictly necessary (in postinst).

Add a check to unbound.postinst whenever openssl is available,
and run unbound-control-setup only if it is.

Add a check to unbound-control-setup whenever openssl is available,
suggesting to install the package it if it is not.

And move openssl dependency from Depends: to Recommends:.  For most
users it will be installed still, but there's a way to uninistall it
if not needed: we use it only once to generate the keys, it is not
used once this is done and the hard dependency is not necessary.