Fix preemption within cohort when there is no borrowingLimit

[mimowo]

What type of PR is this?

/kind bug

What this PR does / why we need it:

To fix handling of preemption within a cohort when there is no borrowingLimit. In that case
during preemption the available resources coming from borrowing were calculated as if borrowingLimit=0.

Which issue(s) this PR fixes:

Fixes #

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Fix handling of preemption within a cohort when there is no borrowingLimit. In that case,
during preemption, the permitted resources to borrow were calculated as if borrowingLimit=0, instead of unlimited.

As a consequence, when using `reclaimWithinCohort`, it was possible that a workload, scheduled to ClusterQueue with no borrowingLimit, would preempt more workloads than needed, even though it could fit by borrowing.

[netlify]

✅ Deploy Preview for kubernetes-sigs-kueue canceled.

Name	Link
🔨 Latest commit	a550f53
🔍 Latest deploy log	https://app.netlify.com/sites/kubernetes-sigs-kueue/deploys/659d8aa02357770008a83d18

[mimowo]

/hold
To investigate a potential bug

[mimowo]

/hold cancel
Should be fixed

[mimowo]

cc @yaroslava-serdiuk @alculquicondor

[yaroslava-serdiuk]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 27ef62c50e345742b36da1faeb527364b7e42818

[mimowo]

/assign @alculquicondor

[alculquicondor]

/release-note-edit

NONE

Because this is a fix for an unreleased feature.

[alculquicondor]

My bad, this is about an existing feature

/release-note-edit

Fix handling of preemption within a cohort when there is no borrowingLimit. In that case
during preemption the available resources coming from borrowing were calculated as if borrowingLimit=0.

As a consequence, when using `borrowWithinCohort` it was possible that a workload scheduled to ClusterQueue with no borrowingLimit would not be scheduled, even though preemption while borrowing could let it schedule.

Also, when using `reclaimWithinCohort` it was possible that a workload, scheduled to ClusterQueue with no borrowingLimit, would preempt more workloads than needed, even though it could fit by borrowing. 

[alculquicondor]

We'll need to make a separate cherry-pick for 0.5

[mimowo]

My bad, this is about an existing feature

Indeed, this is a bug that affects both the existing feature and the new one. I can clean up the release note to only mention the existing feature.

[alculquicondor]

/release-note-edit

Fix handling of preemption within a cohort when there is no borrowingLimit. In that case,
during preemption, the permitted resources to borrow were calculated as if borrowingLimit=0, instead of unlimited.

As a consequence, when using `reclaimWithinCohort`, it was possible that a workload, scheduled to ClusterQueue with no borrowingLimit, would preempt more workloads than needed, even though it could fit by borrowing.

[alculquicondor]

/lgtm

[k8s-ci-robot]

LGTM label has been added.

Git tree hash: 20e4cbe3c067b7a7df474769606211a577266ea9

[alculquicondor]

Don't forget to create a separate PR for 0.5

[alculquicondor]

/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: alculquicondor, mimowo

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 [alculquicondor]

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