captive portal / hostwatch: output safety when list_hosts.py or decoding fails
arp.py seems to throw an exception an unpredictable times. Since
the most likely culprit is list_hosts.py, capture both
stderr of list_hosts and the exception value of the caller.
In any case, we reuse the old known ARP state to not kill
the CP background process
VPN: OpenVPN: add tls-crypt-v2 support (#10069)
* VPN: OpenVPN: Add tls-crypt-v2 support, initial implementation
* Unify key generation into a single bash script that handles stdout parsing and always emits base64, consume that in the key generator
* plist fix
* Add comment that explains stuff a bit better
* VPN: OpenVPN: add tls-crypt-v2 support - refactor https://github.com/opnsense/core/pull/10069
---------
Co-authored-by: Ad Schellevis <ad at opnsense.org>
Services: Kea: DHCPv4/6: Add delete lease command, use socket for up to date lease collection (#10019)
Co-authored-by: Stephan de Wit <stephan.de.wit at deciso.com>
Firewall: Rules [new] - change sorting to interface/group name and stop caring about counted rules, for https://github.com/opnsense/core/issues/9719
Historically this made sense to avoid having to click to all interfaces if this component only serviced a part of it, when moving to this being the standard, this feels less relevant.
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.
