chore: Factor minValues requirements checking into the InstanceTypes methods

[jonathan-innis]

Fixes #N/A

Description

This refactors the minValues code to be reusable by other places were instance types are used and truncated (like in aws/karpenter-provider-aws#6182). It also clarifies some of the usages and checking of minValues.

How was this change tested?

make presubmit

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[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: jonathan-innis

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:

• OWNERS [jonathan-innis]

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

[coveralls]

Pull Request Test Coverage Report for Build 9106406205

Details

• 75 of 80 (93.75%) changed or added relevant lines in 6 files are covered.
• 2 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.03%) to 78.466%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
pkg/cloudprovider/types.go	33	34	97.06%
pkg/controllers/disruption/consolidation.go	16	20	80.0%

Files with Coverage Reduction	New Missed Lines	%
pkg/scheduling/requirements.go	2	97.98%

Totals
Change from base Build 9099680257:	-0.03%
Covered Lines:	8264
Relevant Lines:	10532

---

💛 - Coveralls

[jmdeal]

Do we ever expect this error to be non-nil since min values is still already validated in compute consolidation? It doesn't hurt to have this check, but if there is a new non-nil scenario, I'm wondering if we should still silently fail here.

[jonathan-innis]

It could definitely be non-nil. If we filter out the same type and this breaks the minValues requirement, then we should fail. Also, conceptually, I'd like to keep the semantic with this to be: "when we filter we can fail if our constraints aren't maintained. An error indicates that our constraints weren't maintained."

[jmdeal]

Got it, makes sense to me 👍 When I was reading the original implementation I missed that filterByPriceWithMinValues would return an empty slice when violated so I thought this was a new error check.

[jmdeal]

/lgtm