Fix any code that relies on ParaId -> CoreIndex assignment to be static

[eskimor]

We might still have some code that does not take into account that the association ParaId to CoreIndex can change from block to block.

Comment by Rob:

I think a lot of the places where that assumption is made would manifest as validators accepting or even backing collations for parachains that aren't actually scheduled, although the runtime will not accept such blocks.

As well as not recognizing that the "next up" chain is scheduled - this wouldn't manifest until we have pay-as-you-go cores maxed out.

Therefore, apart from checking the code we should especially make sure to have a test that maxes out all the available on-demand cores.

[eskimor]

Hints by @slumber :

https://github.com/paritytech/polkadot/blob/rh-async-backing-feature/node/network/statement-distribution/src/vstaging/mod.rs#L577
https://github.com/paritytech/polkadot/blob/rh-async-backing-feature/node/network/statement-distribution/src/vstaging/mod.rs#L1772

https://github.com/paritytech/polkadot/blob/rh-async-backing-feature/node/network/collator-protocol/src/collator_side/mod.rs#L510
https://github.com/paritytech/polkadot/blob/rh-async-backing-feature/node/network/collator-protocol/src/validator_side/mod.rs#L498

https://github.com/paritytech/polkadot/blob/rh-async-backing-feature/node/core/provisioner/src/lib.rs#L668

[eskimor]

@antonva also a good ticket to work on.

[eskimor]

All good according to @antonva