feat(conntrack): measure since-last-report bytes/packets lost on GC reap

[Matthew McKeen (mmckeen)]

Description

Conntrack accumulates the bytes/packets seen since the last report on each entry, emits them as previously_observed_* on report events, then resets. When the userspace GC loop reaps an idle-expired entry, that since-last-report residual is dropped and never reported — systematically undercounting traffic on connections that go idle and are reaped between reports.

This measures (does not flush) that lost residual. On GC reap, the entry's tx/rx since-last-report bytes/packets are attributed to ingress/egress from the entry's host-relative traffic_direction (tx is the entry's direction, rx the opposite) and added to two new control-plane counters. This quantifies the undercount without emitting per-flow reap events, which would complicate report parsing.

• conntrack_gc_unreported_bytes_counter{direction}
• conntrack_gc_unreported_packets_counter{direction}

The direction classification is shared with packetparser via flow.TrafficDirection and two small helpers in pkg/utils (TrafficDirectionString, OppositeTrafficDirection).

Related Issue

#1760

Checklist

• I have read the contributing documentation.
• I signed and signed-off the commits (git commit -S -s ...). See this documentation on signing commits.
• I have correctly attributed the author(s) of the code.
• I have tested the changes locally.
• I have followed the project's style guidelines.
• I have updated the documentation, if necessary.
• I have added tests, if applicable.

Screenshots (if applicable) or Testing Completed

Deployed in cluster; the new counters accrue on GC reap and show the previously-invisible undercount by direction.

Additional Notes

Stacked on #2505 — this builds on the conntrack GC delete loop / gcDeletion introduced there. Until #2505 merges, the commit range here includes its commits; the net-new change is the final commit, and this rebases down to just that once #2505 lands.

A follow-up will extend the same counters to the in-kernel deletion path (RST / final-ACK / timeout), reusing the eBPF drop-map pattern from #2503.

---

Please refer to the CONTRIBUTING.md file for more information on how to contribute to this project.