Warning: This build has drifted.
The coverage report for this pull request build may be inaccurate because its base commit is no longer the HEAD of its target branch.
This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.

    • Learn more: For more information on this, see Tracking coverage changes for pull request builds.
    • Fix now: For a quick fix, rebase this PR at GitHub. Your next report should be accurate.
    • Prevent going forward: To avoid this issue with future PRs, see these Recommended CI Configurations.

test: cover the rolling update partition helpers

rollingUpdatePartition decides which replicas a rolling update is
allowed to touch next, and calculateContinuousReadyReplicas and
calculateLWSUnreadyReplicas feed it. A wrong partition either violates
maxUnavailable or leaves the rollout stuck. None of the three had a
direct test; they were only exercised through the integration suite.

Add table-driven cases for the behaviours the code encodes: the ready
tail is counted only while replicas are also updated; replicas without
a state yet count as unready; the partition advances by rollingStep from
the tail, is held while a replica below the window is not ready, still
drops for a not ready replica at the window edge so a broken rollout can
finish, and never moves back up.

Each case was checked by mutation: dropping the updated check, removing
the unavailable guard, letting the partition grow and ignoring missing
states each turn exactly the cases that guard them red.