cmd/containerd-shim-runc-v2: add experimental OOM package

The OOM handling code is intended to live under pkg/oom/v2. However, the
cgroupv2 package still needs further refinement, such as exporting the
cgroup path and allowing callers to query specific stats instead of
returning all of them.

Until that work is complete, introduce the OOM package as experimental
and place it under containerd-shim-runc-v2.

cmd/containerd-shim-runc-v2: use experimental OOM package

We should always send oom event before exit event.

internal/cri/server: check if OOM event occurred before update status

cri-integration: add stress test for TestOOMEventMonitor

The test was validated locally by running 100 pods for 100 rounds without
observing any failures. Due to limited resources in the CI environment,
the test parameters were reduced to 8 pods and 10 rounds.

FOCUS=TestOOMEventMonitor CGROUP_DRIVER=cgroupfs taskset -c 0,1 make cri-integration | tee /tmp/log

*: skip critest OOMKilled testcase for systemd cgroup

With the systemd cgroup driver, the container runtime uses a scope unit to
manage the cgroup path. According to the scope unit documentation:

Unlike service units, scope units have no “main” process: all processes in
the scope are equivalent. The lifecycle of a scope unit is therefore not
bound to a specific process, but to the existence of at least one process in
the scope. As a result, individual process exit statuses are not relevant to
the scope unit’s failure state.

We cannot rely on CollectMode=inactive-or-failed to preserve the cgroup path.
So there is a race condition between containerd and systemd garbage collection.
If systemd GC removes the scope unit’s cgroup before containerd reads it,
containerd loses the opportunity to inspect the cgroup and determine the OOM status.

So we disable the OOMKilled testcase.

In theory, this could be mitigated by inspecting the unit logs (e.g.
journalctl -u XXX.scope) and searching for the "OOMKilled" keyword.
However, this approach depends on journalctl and systemd logging behavior,
so it should be avoided.

Example journal output:

Dec 22 01:24:58 devbox systemd[1]: Started /usr/bin/bash -c dd if=/dev/zero of=/dev/null bs=20M.
Dec 22 01:24:58 devbox systemd[1]: XXX.service: A process of this unit has been killed by the OOM killer.
Dec 22 01:24:58 devbox systemd[1]: XXX.service: Main process exited, code=killed, status=9/KILL
Dec 22 01:24:58 devbox systemd[1]: XXX.service: Failed with result 'oom-kill'.

Ref: https://www.freedesktop.org/software/systemd/man/latest/systemd.scope.html