feat: VPA InPlace updateMode

[omerap12]

What type of PR is this?

/kind feature

What this PR does / why we need it:

VPA InPlace updateMode support.

Which issue(s) this PR fixes:

Fixes #8720

Special notes for your reviewer:

Does this PR introduce a user-facing change?

The VPA support InPlace update mode. VPA will not evict any pods and only try to resize pods inplace.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

AEP: https://github.com/kubernetes/autoscaler/pull/8818

[k8s-ci-robot]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: omerap12

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• vertical-pod-autoscaler/OWNERS [omerap12]
• vertical-pod-autoscaler/pkg/apis/OWNERS [omerap12]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[omerap12]

This is a draft since we need the AEP to be merged first.
/cc @adrianmoisey @maxcao13

[iamzili]

I plan to review this PR more thoroughly after the AEP is merged into main, but let me add one more comment:

I would like to see an e2e test that covers the case described in the AEP:

autoscaler/vertical-pod-autoscaler/enhancements/8818-in-place-only/README.md

Line 180 in f46365c

- Failed Update - Retry Success: Update fails initially, conditions improve, verify successful retry

For example, by starting another large pod, then attempting to update the first pod, observing the failure, and finally killing the large pod, then the in-place update should succeed in the next updater loop.