Use namespace and type for task queue routing

[dnr]

What changed? Task queue routing (choosing which matching node handles a particular task queue) currently depends on the task queue name only. This means two task queues in different namespaces, but with the same name, always end up on the same node.

This changes it to include the namespace id and the task queue type when doing the consistent hash to pick a matching node. The old/new behavior is switched using a dynamic config matching.useOldRouting, which defaults to false (i.e. new routing).

To upgrade smoothly, operators should set that dynamic config to true before the upgrade, then after all nodes are upgraded, switch it to false. This will disrupt task queues for ~10-20 seconds.

The type is also now included in the routing key. The implementation of ListTaskQueuePartitions depended on the fact that workflow and activity task queues with the same name were on the same node, so that was changed to make two calls from frontend instead.

Why? For scheduler and batcher and maybe other things, we'll be creating task queues with the same name in different namespaces and we want to spread out the load. Also it just helps spread the load better in general.

How did you test it? integration tests

Potential risks This will create a little disruption during upgrades. The dynamic config reduces it. An alternate scheme involving forwarding was deemed too complicated.

Is hotfix candidate? no