Detect system info + available BPF features on startup

[patnebe]

Context

• Early detection of system info and BPF features to ensure the required runtime dependencies are met.
• This information will also provide a better UX through improved error reporting on startup.

Changes

• Add a new BPF program to detect what BPF features are available on the host.
• Check that procfs and tracefs are mounted.
• Check support for tracepoints, perf_events, and a few bpf helpers.

Test Plan

• Manual tests + Unit(? / integration?) tests.

[patnebe]

We might want to look into the kernel test errors,

FWIW, the error seemed to be related to the unavailability of the hrtimer_start_range_ns kprobe (or maybe kprobes in general on the VM?). Perhaps some kernel flag is missing(?). So instead of spending time figuring out how to get that to work, I decided to hook the BPF feature detection program to a tracepoint instead. The main reason is that we already rely on tracepoints and currently don't use kprobes anywhere else.

another thing we could do was moving all this code that is pretty much self-contained (and potentially) reusable to a top level crate similarly to how lightswitch-proto is implemented. What do you think?

That sounds reasonable. Maybe lightswitch_sys_probe would be a good name for this crate? Open to suggestions :)

[javierhonduco]

FWIW, the error seemed to be related to the unavailability of the hrtimer_start_range_ns kprobe (or maybe kprobes in general on the VM?). Perhaps some kernel flag is missing(?). So instead of spending time figuring out how to get that to work, I decided to hook the BPF feature detection program to a tracepoint instead. The main reason is that we already rely on tracepoints and currently don't use kprobes anywhere else.

Makes sense!

That sounds reasonable. Maybe lightswitch_sys_probe would be a good name for this crate? Open to suggestions :)

What about lightswitch-features-probing / lightswitch-capabilities or something like this? -sys is typically used for C bindings