bpfilter

As mentioned in #389, when replaces a chain, the new BPF program starts with a zeroed counter map. The behavior should be that when updating a specific entity within a chain (set, rule, etc.), the counters should be preserved (see @qdeslandes comment below for more details and rationale). This PR adds that behavior specifically for , while leaving the existing behavior for . Notes/Thoughts: With the current implementation, counters are copied from the old map to the new map after the new program is loaded but before the link swap. This means that it is possible for some packets to be unaccounted for in the time between the data being transferred and when the new chain begins filtering. While it is possible to keep the same maps (and thus the exact number) since we know the number of rules will be the same, doing that would require a more invasive approach (the flag would need to propagate into more methods) and will not work for or . A enum is added for flexibility in case we need future arguments as opposed to a boolean (which is simpler but harder to work with if we need to use or update this in the future). However, the goal either way should be for this to be temporary (in line with the consolidated behavior mentioned here). ~## Design~ ~The implementation assumes:~ ~Chains may have large numbers of rules, sets, and set elements, but rules won't have exceedingly large numbers of matchers~ ~Update overhead should remain negligible relative to program generation and loading~ ~Simplicity is preferred over hyper-optimizations where possible~ ~Set mapping. Because set matchers reference sets by position and positions can change between chains, a set index mapping is built first. To efficiently compare large sets, old sets are hashed (FNV-1a with commutative element sum for order-independence), sorted by hash, and binary-searched for each new set. Hash matches are verified deterministically with , which copies each set's elements into a flat array, sorts them, and compares with memcmp.~ ~Rule matching. Rules are hashed the same way - FNV-1a of scalar fields plus a commutative sum of per-matcher hashes. A new rules set matchers hash their mapped old index so equivalent rules produce identical hashes regardless of set position (this abstracts away the whole idea of the set so we don't need to worry about it). Old rules are sorted by hash and binary-searched for each new rule, with full order-independent matcher comparison to verify matches. Once again, hash matches are verified deterministically using .~ ~Counter transfer. For each matched pair, the old counter is read and written to the new program's counter map. Policy and error counters are always preserved. This happens after but before , so there is no race.~ ~## Performance Tested with up to 10k rules and 100 sets of 50k elements each. The mapping and transfer overhead was negligible relative to program generation and loading.~ Test plan Added tests to and Manual testing ~Unit tests for and ~ ~E2E test covering rule reordering and set index shuffling~