Added metrics for when we rate limit

[jakobht]

What changed?
Add metrics and logs for when we rate limit workflowIDs

Why?
We need to have observability on the workflow ids we rate limit

How did you test it?
Tested locally and in unit tests

Potential risks
It might cause excessive logging, but it is at most one log (extra) per GRPC call, so I expect it's ok

Release notes

Documentation Changes

[coveralls]

Pull Request Test Coverage Report for Build 018d6eb9-8f0c-484f-8138-3f55479d8974

• -3 of 23 (86.96%) changed or added relevant lines in 2 files are covered.
• 59 unchanged lines in 8 files lost coverage.
• Overall coverage increased (+0.03%) to 62.675%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
common/log/tag/tags.go	0	3	0.0%

Files with Coverage Reduction	New Missed Lines	%
common/persistence/historyManager.go	2	66.67%
service/history/task/transfer_active_task_executor.go	2	72.22%
common/persistence/statsComputer.go	3	94.64%
service/matching/taskListManager.go	3	80.2%
service/history/task/transfer_standby_task_executor.go	4	86.19%
common/persistence/sql/workflowStateMaps.go	11	83.84%
service/history/execution/mutable_state_task_refresher.go	14	64.56%
service/history/task/task_util.go	20	70.57%

Totals
Change from base Build 018d6bf0-6d52-40ca-b6f4-6cd23f6e66a1:	0.03%
Covered Lines:	92114
Relevant Lines:	146970

---

💛 - Coveralls

[Groxx]

Log spam: eh, it's probably fine tbh. Zap samples by default, per log message (the first string arg). And if we decide we do need something fancier or more control beyond that, we have plenty of options.

(I believe we have this disabled internally, but we should probably rethink that. and a log per rpc is far from a major increase anyway.)

[Groxx]

Some minor tweaks worth doing I think, but merge when ready :)

[Groxx]

Tiny thing to fix in the tests, but LGTM once that unblocks :)