[v1] Rolling updates (scaleUp/Down) are processed one pod per reconciliation cycle

Summary

In v1, when upgrading TiDB pods (image/config/resource changes), the upgrader
processes exactly one pod per reconciliation cycle, regardless of how many
pods need updating.

Affected Component

pkg/manager/member/tidb_upgrader.go (and equivalent for TiKV, TiFlash, PD)

Root Cause

tidbUpgrader.Upgrade() iterates pod ordinals from highest to lowest and calls
upgradeTiDBPod() which sets the StatefulSet RollingUpdate.Partition to that
one ordinal. The reconciliation then returns and waits for that pod to become
available before proceeding to the next ordinal in the following cycle.

Impact

For N pods needing rolling updates, N reconciliation cycles are required — each
cycle introducing overhead from pod restart time, readiness probe wait, and
controller cache sync.

Related

• v2: https://github.com/pingcap/tidb-operator/issues/6756

Environment

• Version: v1 (pkg/manager/member)
• Applies to: TiDB, TiKV, TiFlash, PD upgraders

Start with pkg/manager/member/tidb_upgrader.go, tracing tidbUpgrader.Upgrade() and upgradeTiDBPod(), then compare the equivalent TiKV, TiFlash, and PD upgraders. Verify how StatefulSet RollingUpdate.Partition and reconciliation readiness interact. Done means eligible pods no longer require one reconciliation cycle each, with the behavior consistently addressed across the listed upgraders.