Adds fix for domain ack level issue

[davidporter-id-au]

It seems possible for ack levels to be higher than the last message. During this scenario domain updates aren't propagated (if the ack-levels are already in memory) because the replication won't fetch them. This is a guardrail against this.

Why?

How did you test it?

Potential risks

Release notes

Documentation Changes

[coveralls]

Pull Request Test Coverage Report for Build 01837ba5-78de-40a6-9708-ddba588134c1

• 20 of 24 (83.33%) changed or added relevant lines in 2 files are covered.
• 138 unchanged lines in 20 files lost coverage.
• Overall coverage decreased (-0.04%) to 57.25%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
common/persistence/nosql/nosqlQueueStore.go	10	12	83.33%
common/persistence/sql/sqlQueueStore.go	10	12	83.33%

Files with Coverage Reduction	New Missed Lines	%
common/types/shared.go	1	41.66%
client/history/client.go	2	38.1%
client/history/metricClient.go	2	45.3%
common/membership/hashring.go	2	83.54%
common/persistence/executionManager.go	2	78.83%
common/persistence/historyManager.go	2	66.67%
common/persistence/statsComputer.go	2	93.57%
service/history/execution/mutable_state_util.go	2	36.14%
service/history/handler.go	2	47.3%
service/history/task/transfer_active_task_executor.go	2	72.15%

Totals
Change from base Build 01837acb-612f-49b4-a5f2-42785748a233:	-0.04%
Covered Lines:	85113
Relevant Lines:	148670

---

💛 - Coveralls

[Shaddoll]

How does sql implementation handle this?
I'm wondering there might be a general big issue breaking assumptions we make on this component.

[davidporter-id-au]

No idea, let me check

[davidporter-id-au]

It's making the same assumption. You want me to add the check for both?