clear drainage status of a rollbacked version workflow (#8119)

- When a deactivated (drained/draining) version gets rollbacked to
becoming active again, the drainage information that was associated with
it will get cleared.
- This is required because when this version were to get deactivated
again, we need the code to start the drainage process on it again. Right
now, it was not doing that since we were not clearing the drainage
information which did not start a fresh drainage tracker for this
version!

*NOTE*: This change requires a patch to be present. This is because when
this scenario is replicated in production, it will result in two new
history calls (syncSummary as well as a CAN of the version workflow).
This will specifically happen when the rolled-back version gets
deactivated eventually, over
[here](https://github.com/temporalio/temporal/blob/ada5d0bbee45150888b63a132be8239fd5a87212/service/worker/workerdeployment/version_workflow.go#L546)
- note how previously, since the drainage information was not cleared,
[this](https://github.com/temporalio/temporal/blob/ada5d0bbee45150888b63a132be8239fd5a87212/service/worker/workerdeployment/version_workflow.go#L261)
was never executed!)

*How did I verify that this requires a patch*:

- Ran the replay test script before the fix introduced in this PR and
noticed:
<img width="793" height="79" alt="image"
src="https://github.com/user-attachments/assets/bb975d26-4ad1-4847-b477-b74c7d2f55e4"
/>

- Ran the replay test script after the fix introduced in this PR and
noticed:
<img width="911" height="99" alt="image"
src="https://github.com/user-attachments/assets/ad3ff3e1-666a-49b4-bda4-e05f3412d984"
/>

In other words, the total number of our entity workflows went up after
introducing this change and thus requires a patch gate!

- we found a bug in the versioning entity workflows and this is an
effort to fix this!

- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [x] added new functional test(s)

- yes, there is a risk of NDE's happening in production but I mitigated
that risk by placing the fix against a version gate.

Author: Shivs11

config/dynamicconfig/development-sql.yaml

@@ -32,6 +32,10 @@
 #  - value: true
 # matching.PollerHistoryTTL:
 #   - value: 1s
+# matching.wv.VersionDrainageStatusVisibilityGracePeriod:
+#   - value: 5s
+# matching.wv.VersionDrainageStatusRefreshInterval:
+#   - value: 5s
 system.enableEagerWorkflowStart:
   - value: true
 limit.maxIDLength:

service/worker/workerdeployment/replaytester/generate_history.sh

@@ -7,6 +7,8 @@
 #
 # system.enableDeploymentVersions=true
 # matching.PollerHistoryTTL=1s
+# matching.wv.VersionDrainageStatusVisibilityGracePeriod=5s
+# matching.wv.VersionDrainageStatusRefreshInterval=5s
 #
 # Then run this script.
 #
@@ -18,8 +20,8 @@ version="1.0"
 # Expected workflow counts - users can override these if their changes are expected to generate more workflows which will be true when a breaking change to 
 # these worfklows is introduced.
 # These values are used by the replay tester to validate that your workflow changes haven't accidentally created additional executions.
-EXPECTED_DEPLOYMENT_WORKFLOWS=${EXPECTED_DEPLOYMENT_WORKFLOWS:-8}
-EXPECTED_VERSION_WORKFLOWS=${EXPECTED_VERSION_WORKFLOWS:-10}
+EXPECTED_DEPLOYMENT_WORKFLOWS=${EXPECTED_DEPLOYMENT_WORKFLOWS:-12}
+EXPECTED_VERSION_WORKFLOWS=${EXPECTED_VERSION_WORKFLOWS:-14}
 
 echo "📋 Expected workflow counts:"
 echo "   Deployment workflows: $EXPECTED_DEPLOYMENT_WORKFLOWS"

service/worker/workerdeployment/replaytester/testdata/run_1753989718/expected_counts.txt

@@ -0,0 +1,6 @@
+# Expected workflow counts for replay testing
+# Generated by generate_history.sh on Thu 31 Jul 2025 15:21:59 EDT
+EXPECTED_DEPLOYMENT_WORKFLOWS=12
+EXPECTED_VERSION_WORKFLOWS=14
+ACTUAL_DEPLOYMENT_WORKFLOWS=12
+ACTUAL_VERSION_WORKFLOWS=14