Default max CPU handling assesses max CPUs while still in upper-layer runtime's cgroup about kata-containers

[egernst]

1. We grab and validate the config as part of katautils, where we check what max CPUs should be
2. We call createSandboxConfig with the sandbox config created from step 1. This'll then:
   a. create the sandbox (structures)
   b. setup the network
   c. Move itself into the appropriate resource controller
   d. Start the VM.

katautils depends on virtcontainers, so we can't reuse / call logic for getting default max CPUs again from vc. Reordering creation of resource controller to earlier is complicated b/c we rely on devices getting setup. I think the best option would be to update the value of s.hypervisorconfig.defaultMaxVCPUs between 2.c and 2.d, and figure out how to either reuse existing code, or move the logic out of katautils. 🤷

[egernst]

The max handling is a bit of a mess to untangle given that we are checking at LoadConfiguration time. Rather than reorder or change too much, I think it makes sense to do what we have in the confirmation toml comments: Validate only against the number of actual CPUs on the host system, not what is visible to the particular process via go runtime. I'm working to just update checking procfs to see number of logical CPUs instead of calling the go runtime to determine.