It's probably still best to prevent editing associated rules as we can not guarantee settings stick, for unassociated rules, we should be able to edit them.
Fixes missing type in the process here (on firewall rules).
1. For a floating rule with a single interface group, the interface
count and tooltip did not show when viewed from an interface rules page.
2. For a floating rule with an interface group and at least one other
interface or interface group, the entire rule did not show when viewed
from an interface rules page for which the interface is contained in one
of the interface groups.
When multiple interfaces are selected, these will render into separate rules in which case it might not be clear what the outcome would be, specifically when choosing something else than "pass" (pass lan,wan would lead to two rules which match either lan or wan, block lan, wan would lead to random behavior for example).
For https://github.com/opnsense/core/issues/6902
refactor javascript code and move it into opnsense_legacy.js for reuse. while here add a standard controller we can use to query existing categories and allow usage from the components in scope of this change.
Keep current selection in the user session so selections are sticky among tab changes and edits. The previous "hack menu" was a bit impractical to expand to other components as well.
o replace type ahead with tokenizer (mutli select) while here, since the type ahead needed fixes which we rather don't copy to the other firewall sections
o we might want to change the model serializeToConfig() and reload and send it to a separate function in config.inc later to ease migration later. Part of it could be separated with a callback, but it's not super needed
o hook categories into model for firewall rules
Currently the direction of the traffic can only be chosen in floating rules, but in some scenario's it's much easier to create outbound rules (only inbound is supported now).
When using a lot of interfaces, which should all be allowed to access devices on one specific interface, this would save quite some rules and is easier to track for the administrator.
This feature adds direction as on option and while already changing these pages, also allow to create "non quick" rules on interfaces.
Functionally the "regular" rules would be more aligned with the "floating" rules as we have now, with the exception that you can't add multiple interfaces in a normal rule due to the inability to reorder a single rule in multiple rulesets (rules are positional).
Policy based routing on outbound rules is not supported on the interface rules for now, since it would probably lead to confusion.
The old configuration defaults still apply, when writing an entry, both quick and direction are saved as well (default quick + in).
