update(deps): bump to libs 0.21

[therealbobo]

No description provided.

[irozzo-1A]

Thanks @therealbobo, this is great! and should address #2165 as well without having to cherry-pick fixes in the 0.20. libs branch.
Apart from a few nits, I think there are a few things we should address though.

1. I got a segfault when trying it this way, to be further investigated, but I think this may be related to: falcosecurity/plugins#1019

$ sudo build/userspace/sysdig/sysdig --modern-bpf -p"%container.name" container.name!=host
dir: /usr/local/share/sysdig/plugins/
Segmentation fault

2. IMO we should better handle the case in which the container plugin is not present in the fs, it's true that this should not happen when installing sysdig through package manager, but I think loosing the ability of using it standalone could be a limitation, especially for dev experience. I left a dedicated comment for this.
3. falcosecurity/plugins#1046 we fixed a memleak with CRI container runtime we should probably cherry-pick to the container plugin version that works with libs 0.21, not a blocking point maybe as this should be less critical for a tool as sysdig, but we should consider it IMO

[irozzo-1A]

@therealbobo Unfortunately the latest plugin version 0.42 is not compatible with the libs 0.21, because the required plugin API version is too low:

cannot load plugin /usr/local/share/sysdig/plugins/libcontainer.so: plugin required API version '3.12.0' not compatible with the framework's API version '3.11.0': framework's minor is less than the requested one

I'm checking if we could cherry-pick falcosecurity/plugins#1019 and falcosecurity/plugins#1046 and create a 0.3.2 plugin release.
cc @leogr

[irozzo-1A]

I'm checking if we could cherry-pick falcosecurity/plugins#1019 and falcosecurity/plugins#1046 and create a 0.3.2 plugin release. cc @leogr

This should make it, instead of cherry-picking the required changes to a previous version, we could make sure the container plugin is still compatible with libs 0.21.

[irozzo-1A]

/lgtm