The parent task is about spiky connections to MySQL and the current theory is that the reason for that is the fact that ChangeProp only supports global concurrency limits, so when a big batch of jobs for a wiki from a particular shard comes, all the global concurrency is allocated to this particular DB shard and for a single shard it's too much - thus the 'smoothing' that concurrency limiting provides globally doesn't help on the database level.

In order to fix that, we need per-db-shard concurrency. In order to do that, we probably need to partition the topics where we need it by db shard, thus we need to solve T157822 first.

Other issues is that we need to create a custom partitioner that will be aware of the mediawiki-config dbname-shard naming, preferably without copy-pasting the shards mapping into the Event-Platform repo.

Last, ChangeProp should support per-partition concurrencies and (since partition names are just numbers in kafka) we need to integrate the db-partition mapper into change-prop as well somehow.