Leverage remote partitions for exclusive CPUs (Linux 6.7+)

Linux 6.7 added support for "remote partitions", which enables containers to allocate exclusive CPUs without modifying any other cgroups. With the deprecation of cgroups v1, we should migrate CPU manager to leverage this approach.

Background

Currently, with static CPU policy, cpu_manager runs a reconcile loop (default 10s period) to sync CPU allocation to containers. It manages a default set, and every container that doesn't have exclusive CPUs gets assigned the default set. The default set is updated (for every container) to remove CPUs as they're allocated exclusively.

Problems with this approach:

1. Eventual consistency: When an exclusive CPU is assigned, there is up to 10s (or more!) delay before that CPU is removed from the default set of other containers.
2. No protection from system processes: Only containers managed by the Kubelet are excluded from using the assigned CPUs. System processes (e.g. the Kubelet itself) can still be scheduled to it.
3. Every static CPU assignment (or release) requires updating every other container on the node. These are all done through UpdateContainerResources requests, and are subject to global NRI locks.
4. Container reconciliation outside of SyncPod: the reconcile loop calls UpdateContainerResources directly. Normally, all direct container operations like that happen within SyncPod. Performing the operation outside of SyncPod makes this more prone to race conditions.

Proposal

1. The full set of assignable CPUs is written to cpuset.cpus.exclusive on the full cgroup tree (kubelet.slice, kubelet-kubepods.slice), and pod-level cgroups.
2. When a container is assigned exclusive CPUs, it sets cpuset.cpus.exclusive to the assigned set, and cpuset.cpus.partition=root (some specialized workloads like DPDK may want isolated). This is set on container creation, or in doPodResizeAction on resize, both of which are in SyncPod.
3. Remove the cpu_manager reconciliation loop: it's no longer needed.

/sig node /kind feature /cc @pravk03 @ffromani @dchen1107 @Chunxia202410 @lukaszwojciechowski @esotsal