Unix sockets support

[grcevski]

This PR adds support for running TCP and HTTP connections over unix sockets. These are different than the regular TCP sockets because they run streams across mapped files on disk. The setup is always on the same host, so the context propagation can be done with our black box context propagation.

Couple of things related to this addition:

1. I managed to find Linux kernel APIs which specifically work with unix sockets, rather than using probes on read/write/readv/writev/recvfrom. This makes the implementation performant.
2. I had to come up with a way to correlate the sending and receiving side. After bunch of research I realized that we can use the inode numbers of these sockets and correlate them. When these unix_socket APIs are used we can cast the struct sock pointers to struct unix_sock, which allows us to see the peer socket.
3. I overloaded the meaning of the connection information we use everywhere for keys with using the inode number and the peer inode number as pairs.
4. There is a slight complication with the initial send request that the client makes over the unix socket. Until the first send completes the peer inode number appears to be 0, so we don't have it. I had to add code to fix it up after the receiving side replies and they start talking.

TODO:

• Integration tests

[codecov]

Codecov Report

Attention: Patch coverage is 83.33333% with 2 lines in your changes missing coverage. Please review.

Project coverage is 81.01%. Comparing base (8f545d9) to head (f50b92b).
Report is 6 commits behind head on main.

Files with missing lines	Patch %	Lines
pkg/internal/ebpf/common/tcp_detect_transform.go	0.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1436      +/-   ##
==========================================
+ Coverage   80.88%   81.01%   +0.13%     
==========================================
  Files         149      149              
  Lines       15117    15130      +13     
==========================================
+ Hits        12227    12258      +31     
+ Misses       2290     2278      -12     
+ Partials      600      594       -6     

Flag	Coverage Δ
integration-test	59.77% <83.33%> (+0.57%)	⬆️
k8s-integration-test	59.42% <83.33%> (+0.06%)	⬆️
oats-test	33.63% <83.33%> (+0.05%)	⬆️
unittests	51.66% <0.00%> (-0.10%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rafaelroquetto]

Amazing! Good stuff! LGTM 🥇

[rafaelroquetto]

non-rhetorical question: why is the double read required? Would something like the following not work?

const struct unix_sock *usock = BPF_CORE_READ(sock, sk);

?

[grcevski]

Ah thanks for catching it, it's a left over from some earlier changes.

[rafaelroquetto]

nit: I'd not reuse the variable here, I found it a bit confusing - for instance, it begs the question: after a successful the call to read_iovec_ctx, should the new copied len match the older one? If not, why are they expected to be different?

[grcevski]

I can split it in another variable, but iovecs read with a loop and it's limited in how many iterations we do, so we may not read the full buffer.

[rafaelroquetto]

in this case, is this equivalent to:

struct unix_sock *usock = unix_sock_from_sk(sk);

?
If so, then that will save us a few extra reads

[grcevski]

Yup, another code iteration I guess, we don't need to re-read it.