Suricata

For now, we think it's safer to ban the usage of bypass keyword in firewall mode.

Probably something like: accept:flow,bypass, for firewall rules, only.

The ban would still persist for the keyword for threat detection/ ids rules, in firewall mode, though.

A PR in draft, for review: https://github.com/OISF/suricata/pull/15955

In summary, what we have discussed is that the bypass keyword probably shouldn't be valid with most combinations of action and scope, as well as in threat detection rules, in firewall mode.

There are some corner cases to still be tested and ensure we're applying the bypass at the correct time. Automated review indicates that in the case of a single packet flow with a Threat detection drop, we may not get the expected behavior, if we that packet also triggers a `bypass` firewall rule, due to when the engine(s) processes and applies the firewall rules and local bypass action.

Add to current work:
- if bypass is local, pre-flow rules will still be processed and invoked.
- SV test for the above

Follow-ups:
- Special hook pre-flow:
- ban bypass + SV test(s)
- Special hook pre-stream:
- allow bypass + SV test

TBD whether we would want to allow drop:flow + bypass at some point, but we might.