Use InPlacePodVerticalScaling feature gate instead of tweaking cgroups

[norbjd]

The current version (also tagged v0.1.0) is tweaking cgroups to update the CPU requests/limits.

It works, but there are many downsides:

• depending on the cgroups version (v1 or v2), the code is different
• depending on the Kubernetes distribution (kind or kapsule), the code is also different
• the most important: by tweaking cgroups (and bypassing Kubernetes), Kubernetes is not aware of the changes and can start scheduling pods on a node, thinking it has the place to do, while actually all the CPU of the node is already allocated to the existing manually tweaked pods

On Kubernetes 1.27, the alpha feature gate InPlacePodVerticalScaling was introduced (docs here), and this allows to change the CPU without restarting the pod, accomplishing exactly what we're trying to achieve.

The only downsides of using this (that I can see) are:

• the InPlacePodVerticalScaling feature gate is only available from 1.27, so older versions might need to use the "tweaking cgroups" solution in order to boost the pods at startup
• it seems like the pod can take longer to start even with the boost (~1 second with cgroups tweaking, ~3 seconds with the feature gate)

Still, there are more benefits overall than downsides.