follow up: coscheduling queue sort plugin starves pods

[googs1025]

Since the issue #110 has been open for a long time and has not been resolved, I would like to open a new issue as a follow up.

There is no very depth research, but there are roughly two problems I think:

• The sort plugins use InitialAttemptTimestamp to sort, which can easily cause pod starvation for pods enqueue later than pggroup's pod. Not all pods enqueued are managed by the podgroup, and there may be a large number of other pods. Therefore, it seems inappropriate to use only InitialAttemptTimestamp. based on coscheduling queue sort plugin starves pods #110 (comment)

• When considering only InitialAttemptTimestamp enqueue in podgroup, there seems to be other problems: for example, podgroup should also consider minMember, we should satisfy most of the podgroup first, and then satisfy the pods of other numbers in the podgroup.

According to the above, can it be modified like this:

1. Priority Comparison:
   First, compare the priorities of the two Pods.

2. PodGroup Check:
   to get the PodGroup info for each Pod.
   If one Pod does not belong to any PodGroup and the other does:
   We use podInfo timestamp sorting.
   If both Pods belong to PodGroups, proceed to the next step.

3. MinMember Comparison:
   For Pods belonging to PodGroups, check whether each PodGroup has met its minMember requirement.
   Give priority to PodGroups that have not yet met their minMember.
   If both PodGroups do not meet their minMember or both meet their minMember, compare the creation time of the PodGroups.

[googs1025]

similar issue: #110 (comment)

[googs1025]

@Huang-Wei @ffromani Could you please help me see if there is any problem with this idea? 🤔

[googs1025]

/kind bug

[Huang-Wei]

FYI: another proposal #661 (closed due to inactivity)