add errmetrics in the BPF code where they are missing.

[kkourt]

494cbe5 introduced errmetrics and they were later improved by #4120, but there are still locations in the BPF code where we don't track unexpected failures.

E.g., calls to cgrp_get_tracker_id.

[FedeDP]

AFAIK we didn't do that in bulk because the errmetrics add instructions and some bpf programs were hitting insns limit issues.
Btw i think this can be a good first issue!

[3u13r]

Thanks for the added context! I'll take a go on improving the situation a bit.

[3u13r]

I have a PR that mostly adds errmetrics around the probe_read calls. Though, as already mentioned, I hit the instruction limit quite fast on 4.19. On 5.10 I could add ~double the amount on errmetric calls.

Since I want to avoid to take the last bit of instruction budget on 4.19, I think we should not add errmetrics around all probe_read calls.

Regarding the calls to cgrp_get_tracker_id I need a bit of clarification:

1. The function itself return 0 in the error case.
2. The Go code handles this gracefully
3. The first eBPF call handles this 0 even with a default fallback
4. The second eBPF just uses the 0 and passes it to userspace (see 2.).

So there are already fallbacks in place and I'm not sure we can classify each return 0 as an error.
So what is the intention with adding errmetrics to the calls of cgrp_get_tracker_id?