Implementing multi-prog attach support

^{Originally posted by **saxena-anurag** April 15, 2024}
This is in context of adding a generic support to attach multiple programs to an attach point (hook) for any program type, a subset of which is currently tracked by #2626.

Looking at the current available solutions on Linux, it looks like there are 2 possible designs we can use:

**OPTION 1: XDP dispatcher approach**
In Linux, `libxdp` uses XDP dispatcher program to "chain" multiple programs to a hook. Salient features:

1. A program defines a priority and chain call action. Lower number means higher priority. Chain call actions are return codes that the program indicates for packets that should continue processing.
2. This feature is specific to XDP only and uses new (libxdp) UM APIs.
3. Priority / chain call actions can be passed either by UM APIs or embedded in BTF data.
4. Default behavior defaults to default priority and default chain call actions for XDP.
5. Programs with same priority are chained as FIFO.

**_Windows Implementation_**:
1. Add new eBPF API to also take priority and chain call actions as input (chain call actions will be uint32, opaque to ebpf runtime)
2. Add support to parse the new BTF data, and embed in native module.
3. eBPF runtime will pass the priority and chain call actions to the extension. Extension has to implement chaining / dispatcher functionality.

**_References_**:
1. https://github.com/xdp-project/xdp-tools/blob/master/lib/libxdp/README.org
2. https://www.youtube.com/watch?v=Fu4L8ewcO70
3. https://lpc.events/event/7/contributions/671/attachments/561/992/xdp-multiprog.pdf

**OPTION 2: Generic attach / detach APIs**
This is the second and newer approach in Linux. Salient features:

1. New flags have been added which can be used with BPF syscalls and libbpf APIs (e.g. bpf_prog_attach()).
2. Flags include:
1. BPF_F_BEFORE
2. BPF_F_AFTER
3. BPF_F_ID
4. BPF_F_LINK
3. There is no priority for each attach. Each program can specify whether it wants to be before or after another program fd / id, or if it wants to be first or last globally.
4. The implementation "adds a generic layer called bpf_mprog which can be reused by different attachment layers to enable multi-program attachment and dependency resolution".

**_Windows implementation:_**
1. Add support for the new flags for existing libbpf APIs, and support for "default" behavior for backward compatibility.
2. As with Linux, prefereably keep the "chaining" logic in ebpf runtime so that each extension does not need to re-implement the same thing. This may require some design as to how will extensions invoke the programs when there are more than 1 programs attached, and do extensions get to make any decision after every program invocation to decide whether to continue program invocation.

**_References:_**
1. https://www.youtube.com/watch?v=EM09k066pB8
2. https://github.com/libbpf/libbpf/commit/d7e583a6eac64a79c21f1a749e6b3d371b884365

**Question**: Which design approach should we take?

**Interim solution proposal**: Since we urgently need support for multi-prog attach for at least SOCK_ADDR hook, while we decide on the approach and design, we can implement this only for SOCK_ADDR in netebbpfext with FIFO logic.