Plumbing to increase pvf workers configuration based on chain id

[alexggh]

Part of #4126 we want to safely increase the execute_workers_max_num gradually from chain to chain and assess if there are any negative impacts.

This PR performs the necessary plumbing to be able to increase it based on the chain id, it increase the number of execution workers from 2 to 4 on test network but lives kusama and polkadot unchanged until we gather more data.

[s0me0ne-unkn0wn]

Nice!
As an idea, we could even put them into the executor params if need be.

[alexggh]

As an idea, we could even put them into the executor params if need be.

Yeah, I thought about that as well, the reason I think this makes sense in the node version, is two fold:

1. No big bang when we change it, since nodes don't upgrade all at once.
2. On the worse case scenario, if this is bad for a given HW node, we can just tell them to downgrade until we figure it out a different solution.

[sandreim]

I don't think this should be in the ExecutorParams which should contain stuff that has consensus implications.

It might be a good idea to expose these to be overwritten by CLI parameter, so if any issues validators can just keep using current version.

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-clippy
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/6024991

[alexggh]

It might be a good idea to expose these to be overwritten by CLI parameter, so if any issues validators can just keep using current version.

Done, let me know if all good now.

[sandreim]

LGTM!

This demands a PRDoc, please add one before merging.