libct/cg/stats: support misc for cgroup v2

[mythi]

Triggered by #3910.

Initial version based on v2 HugetlbStats and the new v2 memory unit tests.

Opens:

• misc available for v1 too but can only be set via unified so this implementation adds stats for v2 only. Add v1 too?
• stats structure. Currently, this adds per resource key MiscStats entries so that stats so that they become easily available.

[eero-t]

Looks OK to me. Code comment, or commit message, could point to misc docs: https://docs.kernel.org/admin-guide/cgroup-v2.html#misc

Triggered by #3910.

Also related to #3849.

[mythi]

Moving this away from "draft" state to get feedback. The implementation is based on https://docs.kernel.org/admin-guide/cgroup-v2.html#misc.

Changes since the initial version: added TestStatMiscPodCgroupEmpty to test the most common scenario (as of today) where misc.* entries are empty (no keys).

[mythi]

@kolyshkin looks like you've worked in this misc area a bit. Any thoughts on this PR?

misc available for v1 too but can only be set via unified so this implementation adds stats for v2 only. Add v1 too?

this is my biggest open, any feedback would be appreciated

[kolyshkin]

lgtm

[ffuerste]

Hello,

Our product development team at T-Systems would love to have this functionality available in runc.

We are currently developing and already operating in production a commercial offering which we call Open Sovereign Cloud (OSC). OSC is positioned as an offering for regulated sectors. Here we cooperate closely with the respective responsible regulatory agencies. These agencies often impose stringent requirements for encrypting workload data, including a provider exclusion. For this use case OSC offers the feature to run confidential workloads in Kubernetes clusters based on the Intel SGX technology.

Our goal for our users is to have these confidential workloads managed in Kubernetes in the same way as non-confidential workloads, which includes their resource management and monitoring. Using for that established concepts, technologies and components, which are well known and widely used is here a key aspect of OSC and one of the main reasons why OSC has already been certified by Gematik for hosting a healthcare application.

In our view, managing EPC memory via Linux cgroups provides the greatest transparency for Kubernetes users and administrators alike. Furthermore, if information about EPC memory consumption can be retrieved directly from the container runtime (as for CPU and main memory), there is no additional operational overhead and troubleshooting is also greatly simplified.

In addition, not introducing a third-party or in-house developed component is a very important aspect for service providers such as T-Systems in regard to external audits. In collarboration with Intel, we are currently planning to implement SGX EPC memory management in OSC according to intel/intel-device-plugins-for-kubernetes#1567.

Therefore, we fully support @mythi 's feature request and are very grateful for the already created PR.

[kolyshkin]

@opencontainers/runc-maintainers PTAL (this is relatively easy to review and won't affect runc itself, only the libcontainer/cgroups users.