unbound: limit duckdb to a single thread in write mode to reduce logger memory usage
After some testing, it seems the duckdb python API has a tendency to
leak (up to a cap), which seems to be mitigated when we limit to a single thread.
Further testing shows that the single logger.py process doesn't
use parallelization when appending dataframes to the db instance
and as such multiple threads are useless to begin with. The heavier
actions are the read actions, which are separate short-lived processes
and do not suffer from the same issue and likely do require duckdb
parallelism to perform properly, so apply the single thread only to
writers.
dashboard:gauge improvements (#10063)
Closes: #8356
*Makes the disk widget become table/bars from grid 2 size onwards
*Adds disk free/used size on the gauge
*Removes parentheses from the memory widget
---------
Co-authored-by: Fabian Rodriguez <317514+MagicFab at users.noreply.github.com>
dashboard: refactor dashboard to use User model instead of direct config access and cut some code in the process.
We might consider adding a Json fieldtype as well to handle the [de]serialisation of the data, but since this is currently the only occurrence in the User class, let's keep this in the controller for now.
themes: add "opnsense-auto" which switches between "opnsense" and "opnsense-dark" depending browser settings, inspired by https://github.com/opnsense/core/pull/9916
It's a bit of an experiment, but since its so small, it shouldn't be an issue to push this to master.
The trick is actually pretty simple, symlink the relevant directories in build to the standard opnsense theme and add a theme.js override to handle the logic.
mvc: a bit of spring cleaning for setActionHook(), result is never used and throwing a UserException is preferred in cases where can't pin a message to a field. closes https://github.com/opnsense/core/pull/10046
radvd: match radvd_enable() more closely for #10044
Users are confused why they can add an entry but their settings are not
being used. This is specifically wrong according to the inventor of
"dhcpd6track6allowoverride" as it circumvents half of its use cases but
more closely matches user expectation.
May cause regression for some people, but not much we can do here other
than not doing it.