Introduce the ability to specify workload type for GetPosixStreamSignals

[JeroenSoeters]

This PR allows for specifying a workload when retrieving the POSIX signals stream. Right now only 1 type of workload is supported (Cell) and only a single Cell can be specified.

To achieve this the eBPF probe now surfaces the cgroup_id and the observe_service has a cache that allows for looking up the cgroup_path for a cgroup_id. With the cgroup_path we can filter out signals relevant to a specific cell.

[dmah42]

this might generate nicer code as an enum and an opaque string "id". oneof is pretty nasty, especially in some languages.

[JeroenSoeters]

We could introduce a "Workload" message with an enum and a string "id" and have this repeated. I need to think this thru a bit though what this means in terms of implementation details for this specific endpoint, as it could get pretty tricky (and not very intuitive) to aggregate POSIX signals for a mix of cells, containers, vms etc.

[JeroenSoeters]

If we start with the ability to stream signals for a single workload, we can potentially layer the ability to capture signals from multiple workloads on top in the future.

[JeroenSoeters]

What do you think about how the API looks now @dmah42? I will create a separate issue to discuss observing multiple workloads.

[JeroenSoeters]

Also, if we want to avoid using oneof b/c of how this gets compiled in different languages, should we capture this in the stdlib docs as a "general rule"? https://aurae.io/stdlib/

[dmah42]

we should probably point to https://google.aip.dev/ and specifically https://google.aip.dev/search?q=oneof which doesn't say avoid it, but it does provide some trade-offs.

[dmah42]

i personally prefer this (with notes) but i think it should be repeated.

[JeroenSoeters]

Should we iterate on the API later? Making this repeated warrants some discussion imo. Like how would the response look like in these cases? For a single workload, the response is just a stream of signals. If you would be able to specify multiple cells/containers etc we would need to return tuples (id, signal). If we allow for a mix of workload types we need to return 3-tuples (workload_type, id, signal) for the user to make sense of the response. Maybe something for an RFC?

[future-highway]

Just leaving comments. Didn't do a full review.

[future-highway]

Setup lints

// Lint groups: https://doc.rust-lang.org/rustc/lints/groups.html
#![warn(future_incompatible, nonstandard_style, unused)]
#![warn(
    improper_ctypes,
    non_shorthand_field_patterns,
    no_mangle_generic_items,
    unconditional_recursion,
    unused_comparisons,
    while_true
)]
#![warn(
    missing_debug_implementations,
    missing_docs,
    trivial_casts,
    trivial_numeric_casts,
    unused_extern_crates,
    unused_import_braces,
    unused_results
)]
#![warn(clippy::unwrap_used)]