Enforce stricter per workflow limit

[yycptt]

What changed?
Enforce stricter default per workflow limit based on our operational experience
More specifically, by default,

• one workflow can receive at most 10k signals
• one workflow can have at most 2k pending activities, childworkflow, signal external workflow or cancel external workflow commands.
  This PR only changes the default value, user can still set override to those configurations.

NOTE: there's no partial acceptance of workflow task response, meaning if a workflow task tries to schedule 3k activities and pending activity limit is 2k, 0 activity will be scheduled. Workflow task will be failed & workflow will enter a stuck state.

To check current usage,

• For 10k signal per workflow limit: check total_signal_count metric (for all operation tag values)
• For those 2k limits, check activity_info_count, child_info_count, signal_info_count & request_cancel_info_count metric with operation=ExecutionStats

How do I know if those limits are exceeded?

• For the 10k signal limit, new signals will be rejected with InvalidArgument (for now)
• For those 2k limit, wf_too_many_pending_child_workflows, wf_too_many_pending_activities, wf_too_many_pending_cancel_requests, wf_too_many_pending_external_workflow_signals metric will be emitted.

Why?

• Consistency

How did you test it?
N/A

Potential risks

• Will break existing workflow implementations

Is hotfix candidate?

• No

[MichaelSnowden]

Please make sure you update our documentation on workflow size limits, and that you also include this in the release notes because it will likely break some users.