[RFC] Introduce log ratelimit

[vlrpl]

The idea is to avoid infinite printouts due to recurring error condition (e.g. unexpected corruption).

Requires 5.12 support (mostly for __sync_val_compare_and_swap).
As of today we roughly support 5.8+ (not really verified, only statically inspected). If that really matters, we can have something like a probe program for BPF_ATOMIC | BPF_CMPXCHG and instruct the probes to fall back to the non-ratelimited flavors.

[vlrpl]

CAS requires v3 instructions support (the patch doesn't have it). Didn't check the actual reason yet (i.e. no full nor partial v3 support) , but clang 14 still seem to crash despite forcing v3.

[atenart]

Did you experience a flooding of eBPF log messages while using Retis? What was causing it?

[vlrpl]

Did you experience a flooding of eBPF log messages while using Retis? What was causing it?

It was observed in some reports (e.g. ovs-related, WRT flow enrichment, IIRC).
In general, this is a potential problem with the hot path and unexpectedly repeated error conditions (although it might not be that severe, as repeated error conditions like that will likely make the event generation unreliable anyways).

[atenart]

As discussed offline, a different approach could be used too with _once variants of the error helpers (we can even make the "once" per-program to not avoid needing shared variables/maps). This has the advantage of not relying on a specific version (as described above).