Handle burstiness of requests well for the dispute coordinator

[eskimor]

We found the dispute-coordinator to be the heaviest subsystem in terms of CPU usage. While performance is worked on, we should also minimize the effects a loaded dispute-coordinator has on other subsystems.

In particular we noticed that load on the dispute coordinator is rather bursty:

backing and approval-distribution no longer wait for confirmation, when sending votes to the dispute coordinator - so they will only be affected directly if the channel gets full. We can mitigate that by providing more leeway for bursts and just increase the channel size.

dispute distribution does wait for confirmation on vote import, but not one by one, but runs a couple of imports in parallel, so we can improve performance here, by increasing the number of parallel requests.

Really crucial are though the reading calls to the dispute-coordinator, like asking fore recent disputes, or statements as this happens for example in the provisioner. Or chain selection asking for the undisputed chain. If ToF is high for messages due to load/bursts on the dispute-coordinator those reads will be significantly delayed, which has direct consequences for those subsystems.

Summary

1. Increase channel size for the dispute coordinator (e.g. to 2000 messages) - this should minimize blocking for other subsystems, which just want to send data.
2. For "reading" messages, that actually ask for data - use the unbounded channel (after confirming that those reads are bounded, but they very likely are).
3. Increase parallelization of requests in dispute-distribution a bit.

Of these 3, I would consider 2 the most important one. Here we should also check how reading of bounded/unbounded channels is implemented. In particular we should ensure that the bounded channel will not starve the unbounded channel, the unbounded channel should be considered "priority".

[eskimor]

Of course the pattern of using the unbounded channel for reading messages, should be considered for other subsystems as well. It actually makes a lot of sense, especially because reading calls, usually are not work initiating - so the unbounded channel should be well suited for them.

So if a message contains a oneshot - strongly consider using the unbounded channel.

[eskimor]

We will punt on point 3 for now, as it is already at 10 and it is quite questionable if increasing that value will improve performance in any way.