make the policy update atomic

[Andreagit97]

With the current implementation, the update of a policy is not atomic. Let's consider some examples

1. Let's say we modify both the mode and values of a WorkloadPolicy

from:
    mode: protect
    allow list: A, B, C

to:
    mode: monitor
    allow list: A

Today, we first update the values and then the mode, so there will be a brief window where the policy becomes:

mode: protect
allow list: A

This could cause a transient problem in the user's workload.
This issue is due to the fact that policy mode and values are in 2 different ebpf maps, so there are 2 different update operations.

2. Our matching strings are saved in 11 ebpf maps. Let's say this is the initial situation

1. stringmap#0: /usr/bin/ls
2. stringmap#1:
3. stringmap#2:
... all empty 

We want to replace /usr/bin/ls with /usr/bin/cat and add a new binary /usr/bin/longgggggggggg, we could endup in a situation where we enforce a mix of the previous state and the new state

1. stringmap#0: /usr/bin/ls
2. stringmap#1:
3. stringmap#2: `/usr/bin/longgggggggggg`
... all empty 

This is again just transient; in the end, we will end up with

1. stringmap#0: /usr/bin/cat
2. stringmap#1:
3. stringmap#2: `/usr/bin/longgggggggggg`
... all empty 

This is because we use multiple EBPF maps to store the matching strings, rather than just one. I'm not even sure this is a real issue, it is probably acceptable to have some ns of a transient state...

Some ideas:

• Use both maps for values and policy mode as proposed here feat: support WorkloadPolicy update when RulesByContainer are updated #141 (comment). We still need to understand if there are any cons of this approach. This will solve issue number 1
• Unify the 11 maps into just one as proposed here policy has no effect when executable path is short #148 (comment). The cons of this approach are more memory usage and some runtime overhead, as reported in the tetragon PR Convert string and char_buf matches to hash look ups cilium/tetragon#1408 (comment). This will solve issue number 2
• evaluate ebpf arena https://lwn.net/Articles/961594/ instead of ebpf hash map

[Andreagit97]

Writing this issue i realized that this is probably an MVP+1. The transient problem described in point 1 is not ideal, but it is probably acceptable in most of real world cases. Maybe having some concrete issues seen in the real world would help us understand how serious this issue is