elastic scaling RFC 103 end-to-end tests

[alindima]

Adds two new zombienet-sdk tests:

• one which verifies that elastic scaling works correctly both with the MVP and the new RFC 103 implementation which sends the core selector as a UMP signal.
• one which spawns a parachain with two collators, but only one of them is using v2 receipts. The parachain will still make progress but without full throughput

Also enables the V2 receipts node feature for testnet genesis config.

Part of #5049

[ordian]

my general comment is that using zombienet-v1 for measuring throughput via timeout will always be hacky and result in flaky tests:

• we are waiting the substrate block height to be at least 20, but our intent is to wait for the next timeslice to kick in - this check might have false positives (block number > 20, but timeslice didn't kick in)
  then we're trying to measure parachain throughput via block height and timeouts - again this is flaky, because we are not starting to wait from 0 - the risk is having "passing tests", but broken functionality

we should switch to using zombienet-sdk tests IMHO, especially for newly written tests. are there any blockers for doing this?

[alindima]

Fair point. I chose not to do this in the beginning because it would have taken a longer time and I was quite busy.
I switched to using zombienet-sdk test now, please have a look

[paritytech-workflow-stopper]

All GitHub workflows were cancelled due to failure one of the required jobs.
Failed workflow url: https://github.com/paritytech/polkadot-sdk/actions/runs/12119271312
Failed job name: build-rustdoc

[ordian]

thanks for the rewrite! looks like it will be less flaky and we can assert more things

[ordian]

are they assigned instantly after the block with assign_core transaction was finalized? don't we need to wait for timeslice 1 here? i guess this is why we had to wait for 20 blocks before in the test