We have a function pair rrd_import() / rrd_export() now, which do
wildly different things even though they've been used for a single
purpose:

(1) rrd_export() writes a string, appends it to the config.xml

(2) rrd_import() takes a parsed config portion, but not as an
    argument, rather as a global config element

(3) There was also an older backup clue which exported files, but
    simply packed them up for restore after boot

If we can get the system to unify the usage we'll end up with a
neat way of backing, restoring and migrating RRD data, although
I'm not sure if this can be fully compatible with the old files.

The admins group has this now, it makes more sense there as several
people ran into the issue of "my user is admin, but cannot login".

Besides, the privilege sets /bin/csh as the user shell, which we don't
use for root as we have /usr/local/etc/rc.initial there.

rc.newwanip, rc.newwanipv6, interface_configure() and interfaces_configure()
all call ipsec_configure_do(), which is no wonder why the code can be prone
to races.

".update" does not bring any value to the table, especially since there
is no other script there and the intent is somewhat clear...

harden ciphers and tls versions

PR:  https://forum.opnsense.org/index.php?topic=4860
See: https://github.com/phalcon/cphalcon/issues/12648

This looks a bit odd when we have the full struct and pass it down,
but is way easier to maintain than to tell the underlying code
this is a server or a client or whatever, because it shouldn't
matter as the vpnid is unique anyway.

Looking at openvpn_configure_server() and openvpn_configure_client()
it becomes a bit clearer why they take a config.xml subset: it's beause
the write_config() ordering was flipped.  We could probably now pass
an ID and let the code figure out if it is a client or server...

Switching the tty causes the terminal to exit, which means
the package upgrade jobs are not done, leaving files in the
system that shouldn't be there.

The $search parameter is unused.

... wrap with array() to proceed!

... that was written at a time when either Unbound or Dnsmasq
could run, but nowadays both can run in tandem which "breaks"
the service widget on the log page.  The log page now belongs
to the Unbound service.

Submitted by: Armin Tüting