This commit introduces the minimal trace events for WireGuard-related
packets. On ingress packets, upon receiving the decrypted packet
either `bpf_host` or `bpf_overlay`, we emit a `TRACE_FROM_CRYPTO_DEV`
even with `TRACE_REASON_ENCRYPTED`, to indicate that the packet comes from
a crypto device because it was encrypted and needed decryption.
Egress packets on `bpf_host` that need to be encrypted will instead be
logged with a `TRACE_TO_CRYPTO_DEV` and the `TRACE_REASON_ENCRYPTED` value.
This will enable an output as follows.

WireGuard with Overlay:

```bash
1:<- endpoint 1180 flow 0x0 , identity 7765->unknown state unknown ifindex 0 orig-ip 0.0.0.0: 10.244.1.122 -> 10.244.2.208 EchoRequest
2:-> overlay flow 0x0 , identity 7765->62609 state new ifindex cilium_vxlan orig-ip 0.0.0.0: 10.244.1.122 -> 10.244.2.208 EchoRequest
3:-> crypto_dev encrypted  flow 0x0 , identity host->unknown state new ifindex cilium_wg0 orig-ip 0.0.0.0: 172.18.0.3:50877 -> 172.18.0.4:8472 udp
4:-> network flow 0xbc383006 , identity host->unknown state unknown ifindex eth0 orig-ip 0.0.0.0: 172.18.0.3:51871 -> 172.18.0.4:51871 udp
5:<- network flow 0xbc383006 , identity unknown->unknown state unknown ifindex eth0 orig-ip 0.0.0.0: 172.18.0.4:51871 -> 172.18.0.3:51871 udp
6:<- crypto_dev encrypted  flow 0x0 , identity 62609->unknown state new ifindex cilium_wg0 orig-ip 0.0.0.0: 10.244.2.208 -> 10.244.1.122 EchoReply
7:<- overlay flow 0x0 , identity 62609->unknown state unknown ifindex cilium_vxlan orig-ip 0.0.0.0: 10.244.2.208 -> 10.244.1.122 EchoReply
8:-> endpoint 1180 flow 0x0 , identity 62609->7765 state reply ifindex lxc67ef7ac0e8eb orig-ip 10.244.2.208: 10.244.2.208 -> 10.244.1.122 EchoReply
```

Wireguard with Native Routing:

```bash
1:<- endpoint 2255 flow 0x0 , identity 15205->unknown state unknown ifindex 0 orig-ip 0.0.0.0: 10.244.1.125 -> 10.244.2.59 EchoRequest
2:-> stack flow 0x0 , identity 15205->33119 state new ifindex 0 orig-ip 0.0.0.0: 10.244.1.125 -> 10.244.2.59 EchoRequest
3:-> 0: 10.244.1.125 -> 10.244.2.59 EchoRequest
4:-> crypto_dev encrypted  flow 0x0 , identity 15205->unknown state new ifindex cilium_wg0 orig-ip 0.0.0.0: 10.244.1.125 -> 10.244.2.59 EchoRequest
5:-> network flow 0x0 , identity host->unknown state unknown ifindex eth0 orig-ip 0.0.0.0: 172.18.0.2:51871 -> 172.18.0.4:51871 udp
6:-<- network flow 0x0 , identity unknown->unknown state unknown ifindex eth0 orig-ip 0.0.0.0: 172.18.0.4:51871 -> 172.18.0.2:51871 udp
7:<- crypto_dev encrypted flow 0x0 , identity world->unknown state unknown ifindex cilium_wg0 orig-ip 0.0.0.0: 10.244.2.59 -> 10.244.1.125 EchoReply
8:-> endpoint 2255 flow 0x0 , identity 33119->15205 state reply ifindex lxc6b5542b90ce7 orig-ip 10.244.2.59: 10.244.2.59 -> 10.244.1.125 EchoReply
```

Inspecting the bpf metrics from a Ciliun node (also collected in sysdumps)
after an encrypted Echo Request/Reply between two endpoints will produce
the following output:

```bash
root@cilium-testing-worker:/home/cilium# cilium bpf metrics list
REASON                    DIRECTION   PACKETS   BYTES       LINE   FILE
...
Interface Decrypted       INGRESS     1         98          1150   bpf_host.c
Interface Encrypted       EGRESS      1         98          1510   bpf_host.c
...
```

For clarity: the `TRACE_REASON_ENCRYPTED` is used even if in the trace
points introduced by this patch the packets have already been decrypted
(TRACE_FROM_CRYPTO_DEV) or still need to be encrypted (TRACE_TO_CRYPTO_DEV).
To make full use of this value and use it where packets are actually
encrypted we'd need additional parsing logic that could be an overkill
since it is just for tracing.

1. For egress packets, `bpf_host` would be able to see packets marked as
    `MARK_MAGIC_WG_ENCRYPTED`, no further logic would be needed. A new
    `TRACE_FROM_CRYPTO_DEV` here could be displayed with the encrypted bit.
2. For ingress packets, we should inspect L4 and check whether is UDP and
    sport=dport=WIREGUARD_PORT, so that we can then trace both the
    network packet with the encrypted bit and display a
    `TRACE_TO_CRYPTO_DEV` with also the encrypted bit.

As far as we don't need to add this additional logic for other reasons,
I wouldn't add complexity in the datapath just for tracing. Looking in
next steps, in the userspace, Hubble/Cilium-dbg could better interpret
these CRYPTO_DEV events they're receiving and elaborate a more complete
output themselves.

Useful discussions: #4801 (Hubble/Cilium-dbg vxlan parsing logic for overlay)

Fixes: #34659

Signed-off-by: Simone Magnani <simone.magnani@isovalent.com>