We previously achieved what we wanted anyway: move all callers
to a single file exclusively dealing with unbound.

There is still some glue in the product info that is irrelevant
to the product.  Will be removed eventually.

It may help users to find what they think are "packages", but
for consistency reasons was recoined as "plugins".

php7.1, Error at /usr/local/opnsense/www/api.php:26 - Invalid callback OPNsense\Core\Api\MenuController::afterexecuteroute, cannot access protected method OPNsense\Core\Api\MenuController::afterExecuteRoute() (errno=2)

PR: https://github.com/opnsense/core/pull/1524

* RFC2136 missed the edit page completely
* DynDNS ACLs merged, we do it by feature

(proxy) virtualip's should be added automatically for listening configuration, this was the case for some types, but not for all (CARP)

Note that require_once is bad as well here, because it throws another
uncatched error as opposed to a warning when a file has not been found.
Now it is better in recovery, although 99% of the time this is supposed
to deal with syntax errors during bad core/plugin updates or manual
user edits.

It's also useful to note that the errors/warnings still make their way
to the crash reporter so we can do something about them.

Suggested by: @fabianfrz

simply eval() it and log the error instead of stopping execution.

We don't get to source the code, but since for strict plugins
there is no direct code execution the plugin acts as if it was
deinstalled.

As the plugin scope is growing rapidly, we need this to be able to
guarantee error-free execution in the widest possible sense.  This
doesn't currently protect function calls, but the same thing must
be done there as well.

PR: https://lists.opnsense.org/pipermail/devel/2017-March/000012.html

PR: https://lists.opnsense.org/pipermail/users/2017-March/000062.html

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.