Tamir Duberstein 3cfd886dc5
log: annotate logging functions inlining
Some of these functions fail to compile when not inlined, so we should
be explicit.

Before deciding on this approach I tried various ways of making all
these functions #[inline(never)] to save instructions but I ran into
blockers:
- These functions currently return Result, which is a structure. This is
  not permitted in BPF.
- I tried inventing a newtype that is a #[repr(transparent)] wrapper of
  u16, and having these functions return that; however it seems that
  even if the object code is legal, the verifier will reject such
  functions because the BTF (if present, and it was in my local
  experiments) would indicate that the return is a structure.
- I tried having these functions return a plain u16 where 0 means error,
  but the verifier still rejected the BTF because the receiver (even if
  made into &self) is considered a structure, and forbidden.

We can eventually overcome these problems by "lying" in our BTF once
support for it matures in the bpf-linker repo (e.g. Option<NonZeroU16>
should be perfectly legal as it is guaranteed to be word-sized), but we
aren't there yet, and this is the safest thing we can do for now.
..
bpf_probe_read.rs Clippy over tests and integration-ebpf
lib.rs integration-test: build-dep on integration-ebpf
log.rs log: annotate logging functions inlining
map_test.rs aya-bpf-macros: Refactor for ease of testing
name_test.rs aya: Find programs using the symbol table
pass.rs aya-bpf-macros: Refactor for ease of testing
relocations.rs Clippy over tests and integration-ebpf
test.rs aya-bpf-macros: Refactor for ease of testing
two_progs.rs integration-test: Add test for 2 progs in same section