Undeprecate branch info and deprecate branch token in history tree (#4852)
Aside from ref counting w.r.t. history branch ancestors, the history
tree table also serves as the data source for history scavenger to scan
over and check if specific history data are considered turds.
Both branch info and branch token have been double-written to since the
branch info field has been initially annotated as deprecated. No need to
perform backfill. This change continues to double write both branch info
and branch token. However, scavenger now uses the branch info to perform
the scan. The branch token double write is in case rollback is involved.
The double write will be removed after the next minor release.
<!-- Describe what has changed in this PR -->
**What changed?**
<!-- Tell your future self why have you made these changes -->
**Why?**
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
**Potential risks**
<!-- Is this PR a hotfix candidate or require that a notification be
sent to the broader community? (Yes/No) -->
**Is hotfix candidate?**
Allow list of keywords in dual visibility setting (#5065)
<!-- Describe what has changed in this PR -->
**What changed?**
Allow list of keywords in dual visibility setting
<!-- Tell your future self why have you made these changes -->
**Why?**
Let dual visibility with Elasticsearch work with list of keywords for
backwards compatibility.
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
**How did you test it?**
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
**Potential risks**
No. Any setting involving standard visibility will work as usual: custom
search attributes are just ignored and not persisted.
<!-- Is this PR a hotfix candidate or require that a notification be
sent to the broader community? (Yes/No) -->
**Is hotfix candidate?**
No.
**What changed?**
Fix unit tests on release branch
**Why?**
The tests assumed that the change to not track ALLOW_ALL workflows was
already active, but it's not on the release branch. So we just need
mocks for WatchWorkflow.
Use ContinueAsNewSuggested in scheduler workflow (#4990)
**What changed?**
Scheduler workflow uses server-sent suggestion for when to
continue-as-new instead of fixed iteration count.
Note this is not enabled in this PR yet.
**Why?**
Automatically handle history size/event count too large conditions (or
any future conditions added by the server), which we might get if we do
more work than expected per iteration.
**How did you test it?**
new unit tests, also replaced for loop with previous version to verify
actual iteration count didn't change
**Potential risks**
The default history size suggestion is at 4MB, which we could hit after
just a few large payload responses, and then we'd do continue-as-new
more often than we might like.