Fix "BPF program too large" error in kernel release 6.4 and greater (#1908)

Fixes #1880, which
contains more details, but the summary is that this commit and greater
prevent our code to load.

```
Author: Eduard Zingerman <eddyz87@gmail.com>
Date:   Tue Jun 13 18:38:23 2023 +0300

bpf: Verify scalar ids mapping in regsafe() using check_ids()
```

I am not super sure of all the effects of that commit above, but it
seems that perhaps the verifier is accounting for more execution paths,
increasing the number of instructions that's analysing, making it go
over the threshold.

This is remediated by reducing the number of instructions we have per
program. Before we packed as many iterations of the main loop as we
could, which now we have to reduce.

A possible side-effect is that for very large stacks we'll have to run
more tail-calls, which while they are cheap, they aren't zero-cost.
There might be some other performance implications, but we need to make
this change for newer kernels, so let's benchmark this later on, but I
don't expect the performance impact to be huge.

Test Plan
=========

Compiled a custom kernel 6.4.7 off
4e382c2b468348d6208e5a18dbf1591a18170889 [0] and run our cpu tests
without any issues, while before we were seeing a failure.

Will add this kernel to our kernel tests in some weeks.

[0]: https://cdn.kernel.org/pub/linux/kernel/v6.x/ChangeLog-6.4.7

Author: javierhonduco

bpf/cpu/cpu.bpf.c

@@ -17,9 +17,9 @@
 /*================================ CONSTANTS =================================*/
 
 // Number of frames to walk per tail call iteration.
-#define MAX_STACK_DEPTH_PER_PROGRAM 15
+#define MAX_STACK_DEPTH_PER_PROGRAM 11
 // Number of BPF tail calls that will be attempted.
-#define MAX_TAIL_CALLS 10
+#define MAX_TAIL_CALLS 12
 // Maximum number of frames.
 #define MAX_STACK_DEPTH 127
 _Static_assert(MAX_TAIL_CALLS *MAX_STACK_DEPTH_PER_PROGRAM >= MAX_STACK_DEPTH, "enough iterations to traverse the whole stack");