Allow completely disabling cgroup manipulation

[aidanhs]

This enables usage of libcontainer etc in situations where you want a rootless container and you do not have access to systemd.

This has been achieved by setting up cgroups once (on container init) and storing the config in the youki_config.json file, then loading it afterwards when it needs to be referenced rather than deriving it from scratch every time. I suspect this will fix bugs with exec not correctly using systemd for cgroups (because subcommands were not performing the check for user namespaces, they just check for the --systemd-cgroup flag).

This is a breaking change to the API, as now use_systemd cannot be overridden on the Container type - this PR makes it a static property of the container once created (like hooks). But I think if people are doing on-the-fly editing of cgroup management for a created container they're already off the happy path of youki anyway.

[utam0k]

Sorry for the late. I'll review this PR next weekend. If you have time to check CIs, please fix it before starting reviewing 🙏

[aidanhs]

Have fixed linting and unit test compilation failures. Have run the unit tests and integration tests as best I can (struggled with WASM ones) and the only failures I get also fail on main.

[utam0k]

This enables usage of libcontainer etc in situations where you want a rootless container and you do not have access to systemd.

Why don't you directly use cgroupv2 fs instead of systemd? Also, I'd like to know more concrete use case you mentioned.

[aidanhs]

The program I'm working on will be distributed to users and I want it to work natively in WSL, without any additional user setup. Currently I use nsjail for rootless namespace isolation (pid and mount only) and have no need for cgroups or anything else.

I'm doing the isolation rootless, WSL uses the unified setup (microsoft/WSL#6662) and also does not have systemd enabled by default - so afaict none of systemd, cgroupsv1 or cgroupsv2 will work for me without some configuration. libcontainer allows disabling most things (via the bundle), but it will always try to access cgroups to create a cmanager (even if you're not applying resource limits or entering a cgroup namespace) - hence this PR.

There were two ways I could tackle this PR:

1. auto detecting usage of cgroup namespaces and/or resources, and using cgroup managers on-demand
2. (current implementation) explicitly disabling cgroup management

I opted against 1 because it removes control from the user - if someone wants the container in a cgroup without resources or cgroup namespaces (e.g. to manage outside of libcontainer), they'd have no way to achieve that.

[aidanhs]

I will say - if your goal is to have libcontainer be a runtime primarily for OCI, rather than a generic 'namespace toolkit' (like nsjail), I understand if you're not interested in this PR.