Refactor VersioningInfo calculation for a TaskQueue

[Shivs11]

What changed?

• WISOTT

Why?

• Cleaner code

How did you test it?

• built
• run locally and tested manually
• covered by existing tests
• added new unit test(s)
• added new functional test(s)

Potential risks

• Not with this PR

---

Note

Refines how current and ramping versions are derived by tracking task-queue membership across data formats and only allowing unversioned selections when not part of any version.

• Worker versioning:
  • CalculateTaskQueueVersioningInfo:
    • Add flags isTaskQueuePartOfSomeCurrentVersion and isTaskQueuePartOfSomeRampingVersion to track membership across legacy and new data.
    • Use these flags when picking latest RoutingConfig so unversioned current/ramping is only chosen if the task queue isn’t part of any version.
    • Set membership flags when finding current/ramping via legacy deployments and versions list.
    • Remove redundant local flags and obsolete nullification checks for routing configs.
    • Continue returning final selections via PickFinalCurrentAndRamping.

^{Written by Cursor Bugbot for commit 877d890. This will update automatically on new commits. Configure here.}

[cursor]

Bug: Unversioned Deployments Blocked by Versioning Mixup

The refactored logic incorrectly blocks unversioned deployments from the new routing config format when the old format contains any current version (including unversioned ones). The removed validation specifically checked if current.GetVersion() != nil to only block when old format had a versioned deployment, but the new flag isTaskQueuePartOfSomeCurrentVersion is set even for unversioned deployments in the old format. This causes the function to ignore newer unversioned routing configs when an older unversioned deployment exists in the old format, violating the timestamp-based selection logic.

 

[Shivs11]

closing this one out