Since -accept_rtadv is always executed, we can combine setting a description to prevent another call to ifconfig, we already need quite some calls which can slowdown configuration.
(FreeBSD 13 seems to be faster, but limiting calls in this case seems like a fair trade)
o add legacy control buttons (edit, clone)
o refactor LegacySubsystemController to include "enable" status and simplify applyConfigAction to be more or less the same as its mvc cousins
o add alternate id fields for phase1/2 search actions
o add toggle phase[1|2] actions
o add toggle IPsec enable action
o copy legacy "apply changes" dialog from key_pairs.volt
o since ikeid is unique for a phase1 entry, we should use it as a unique key there.
o phase2 entries don't have a unique key, in which case we can only fallback to sequence, which has concurerrency issues.
When local or remote isn't set to an ip address every configure will start removing the current device (and thus routes), although hostnames will likely always be a bit wacky (needs resolving, might change in which case the underlaying components likely miss the event). It's probably still a good idea to resolve when no addresses are used before concluding a device has changed.
In the process change ipsec_resolve() to support both IPv4 and IPv6, but to limit risk, keep callers at IPv4 (which was the old behaviour), since it's not entirely sure we can use the phase 1 protocol for the tunnel itself as well.
kern.randompid is read-only on HBSD but in the meantime we also
have a better default so let's use that on 22.1.
See: https://reviews.freebsd.org/D12238
Also it seems that sysctl -ad returns sysctls that the kernel
considers sysctls with no value. These are likely read-only
of some type so bring them in as well with a blank value.
Mark unsupported and read-only with text-danger since their
use is not doing anything for the system.
o Only modify default sysctls when default is known
o Let user know a default is not available for tunable
o Parse system descripton and type and show in GUI
We only ask the tunables configuration layer for the current value
which is likely going to match. We could fetch the actual value
from the system but speed and priviledge separation concerns weigh
heavier.
PR: https://forum.opnsense.org/index.php?topic=24409.0
o move media detection to generic legacy_interfaces_details() parser
o hide options when not applicable (only auto-select means non physical it seems).
Since it's technically not very problematic to support ranges where "any" means either upper or lower bound, we best make sure the values inserted are at least used. (as soon as it's a range, it can't be an alias anyway due to the colon)
There is a small risk of regressions in existing setups where people accidentally used the unsupported input, but this looks like a reasonable risk.
The other option would be to extend the validation and reject the input.
This commit doesn't handle the user input for the "any - static port" type, which currently doesn't seem to be supported. As discussed with @kulikov-a, who might have ideas about the user input part when he has some time.
