/kind feature

There are several problems with the current approach to pod ResizeStatus, including:

1. Race condition setting the status: the kubelet can overwrite the Proposed status set by the API server ([FG:InPlacePodVerticalScaling] Race condition setting pod resize status #125394)
2. Can technically have 2 parallel resize statuses: a {Proposed/Deferred/Infeasible} resize when desired resources != allocated resources, and an InProgress resize when allocated resources != actual resources. Currently the former just overrides the latter.
3. Separate mechanism for surfacing details related to error states (Deferred, Infeasible, stuck InProgress)
4. No status to capture desired memory limit < actual memory usage, which can lead to a resize stuck in InProgress (maybe this should move to the deferred state?)

Before graduating to Beta, we should revisit the design of ResizeStatus, and take a holistic look at the user experience.

/sig node
/priority important-soon
/milestone v1.33
/triage accepted
/cc @yujuhong