Allow to adjust LinuxNamespaces

[champtar]

2 use cases I have in mind:

• add cgroup namespace for k8s privileged pods
• enable time namespace (depends at least on time namespace missing opencontainers/runtime-tools#783)

[klihub]

@champtar AFAICT, this is an alternative implementation of #124.

[champtar]

@klihub indeed ...
Now that I've written it, mine is more fine grained, ie you can add / modify / remove individual namespaces

[champtar]

Ci is broken: /bin/sh: 2: protoc: not found

[champtar]

@klihub as there is some interest in having namespaces adjustment, can you ping the right persons to move this PR or #124 forward ?

[klihub]

Ci is broken: /bin/sh: 2: protoc: not found

It's not CI per se IMO, rather I think some github-related PITA that hits us with regular irregularity.

What happens is that every once in a while for some reason the protobuf source is cloned with a newer timestamp than the compiled bindings. When this happens our build system tries to rebuild them, but can't since we deliberately leave protoc uninstalled... because commits touching the protocol should commit both the protobuf and the generated sources.

Maybe the right thing to do would be to always install protoc and the plugins we need, then always force a recompilation, and finally check that there are no changes. Why I'm reluctant to do that is that it would also implicitly/indirectly force everyone to use the same protoc{-gen-go,} versions, since those are emitted to the generated sources...

Anyway, I retriggered the workflow for you, and it looks like the coin flipped the other way this time, because it succeeded.

[klihub]

@klihub indeed ... Now that I've written it, mine is more fine grained, ie you can add / modify / remove individual namespaces

Currently there is a pair of PRs (#123, #124) with security implications, and it's actively being discussed what additional infra bits we'd need (mostly the ability to lock down selected adjustment capabilities in NRI administratively) so that everybody would feel confident enough about taking those changes in. Your PR is an alternative implementation of #124, so if you have valid uses cases for all of these additional capabilities, could you chime in #124 and point to this PR of yours as an alternative ?