Modify strictReplicaGroup rebalance batching to categorize on current+target instances to partitionId to currentAssignment

[somandal]

This PR modifies strictReplicaGroup rebalance batching to categorize on Pair(current instances, target instances) to partitionId to currentAssignment, instead of partitionId -> current instances -> currentAssignment. It also modifies the code to move a full Pair(current instances, target instances) to partitionId at a time rather than a full partitionId at a time to provide more granular batching.

This is to more closely mimic how strictReplicaGroup instance selection is done, which is based on the assignments and knows nothing about the partitions, or whether partitioning is even enabled. The main objective is to assess segment availability and mark instances as a whole as unavailable if even one segment is unavailable for that instance.

For StrictRealtimeSegmentAssignment, the full partitionId is guaranteed to belong to a single Pair(current instances, target instances), since the IdealState is used to update the segments that are newly assigned. Thus the invariant for consistency purposes that the full partition must move as a whole is still maintained, since the full partition will be part of the same pair. Even when choosing whether the segment can be moved based on availability, the partition will be chosen as a whole or be skipped for move as a whole since the assignedInstances is used for the availability tracking and all segments of a partition will have the same assignedInstances and available instances (which is same as the older rebalance code without batching).

For other segment assignment strategies, the code will now move a full Pair(current instances, target instances) to partitionId as a whole, but it can happen that a partitionId is split across multiple Pair(current instances, target instances). It is okay to move them separately since there is no mandate in these segment assignment strategies that the partition must be moved as a whole or assigned based on IdealState (it is instead assigned based on instance partitions if it exists or the tagged servers). It is enough to ensure that the minAvailableReplicas will be honored based on strictReplicaGroup instance selector, which is done by the original rebalance code already (and utilized even with batching).

Testing done:

Used HybridQuickstart to try the following with strictReplicaGroup instance selector enabled:

• StrictRealtimeSegmentAssignment for REALTIME tables
• RealtimeSegmentAssignment for REALTIME tables
• OfflineSegmentAssignment for OFFLINE tables

Verified the grouping happens as expected, and the full Pair(current instances, target instances) to partitionId is moved as a whole. Non-batching works as expected.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 63.36%. Comparing base (1a476de) to head (688a8b6).
Report is 106 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #15838      +/-   ##
============================================
+ Coverage     62.90%   63.36%   +0.46%     
+ Complexity     1386     1353      -33     
============================================
  Files          2867     2898      +31     
  Lines        163354   165797    +2443     
  Branches      24952    25360     +408     
============================================
+ Hits         102755   105055    +2300     
+ Misses        52847    52807      -40     
- Partials       7752     7935     +183     

Flag	Coverage Δ
custom-integration1	100.00% <ø> (ø)
integration	100.00% <ø> (ø)
integration1	100.00% <ø> (ø)
integration2	0.00% <ø> (ø)
java-11	63.34% <100.00%> (+0.47%)	⬆️
java-21	63.30% <100.00%> (+0.48%)	⬆️
skip-bytebuffers-false	?
skip-bytebuffers-true	?
temurin	63.36% <100.00%> (+0.46%)	⬆️
unittests	63.36% <100.00%> (+0.46%)	⬆️
unittests1	56.39% <ø> (+0.57%)	⬆️
unittests2	33.43% <100.00%> (-0.15%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.