Update to polkadot-stable2412-2-with-backport-8040

[alexggh]

To increase throughput mythical-node needs to pick-up the changes from https://github.com/paritytech/polkadot-sdk/pull/8040/files, which increases the default PoV usage from 50% to 85%. Additionally, a CLI flag is also provided experimental_max_pov_percentage in case 85% is too optimistic and there is a need to go back to 50% or less.

The PR is not backwards compatible, so it can't be included in polkadot-stable2412 branch because it would break everyone, but it will be in polkadot-stable2503 and will be picked automatically.

So, we don't have to wait till the repo gets updated polkadot-stable2503, which will included other changes as well I created polkadot-stable2412-2-with-backport-8040 tag in polkadot-sdk that contains polkadot-stable2412-2 tag + paritytech/polkadot-sdk#8040, nothing else.

Unfortunately, pallet-collator-staking needs to be updated, because otherwise compilation fails because of other mismatches, so I created a PR there as well blockdeep/pallet-collator-staking#44, but we need a tag version for it before this PR can be merged.

[Moliholy]

@alexggh changes look good, but this is not meant to be merged, isn't it? Instead, this is supposed to be just for testing purposes in testnet environments. If you want I can port it to a different branch and in any case keep opening PRs to that branch. Does that sound good?

EDIT

Heh, never mind, you actually have writing access to the repository, obviously. Then we can simply discard this PR and use your branch or any other you may want to create.

[alexggh]

@alexggh changes look good, but this is not meant to be merged, isn't it? Instead, this is supposed to be just for testing purposes in testnet environments. If you want I can port it to a different branch and in any case keep opening PRs to that branch. Does that sound good?

This is meant to be merged, so that we have a mythos-node release that consumes this PR:https://github.com/paritytech/polkadot-sdk/pull/8040/files, so that we don't have to wait stable2503 to be integrated.

What would prevent the merging ?

[web3gautam]

Can we create a tag from this branch and build a node from that? We shouldn't be merging code that is not part of a release. And if these changes are going to be part of 2503 anyway, we can wait for that update a couple of weeks.
In the meantime, for testing on local and testnets, you can build a node from this branch/tag directly. @sandreim

[Moliholy]

I have triggered both runtime and node builds based on the branch of this PR. That can be used for testing for now. We will soon upgrade the node to stable2503 and then we can close this PR.

[sandreim]

Can we create a tag from this branch and build a node from that? We shouldn't be merging code that is not part of a release. And if these changes are going to be part of 2503 anyway, we can wait for that update a couple of weeks. In the meantime, for testing on local and testnets, you can build a node from this branch/tag directly. @sandreim

I think decision to wait for 2503 or not should be taken based on data. Are the optimizations in #290 enough given the current load and growth for the next month ?

Mythical team should make this call.

I have triggered both runtime and node builds based on the branch of this PR. That can be used for testing for now. We will soon upgrade the node to stable2503 and then we can close this PR.

I think we should do that after we merge #290 and rebase this PR on it.
We can build both node and runtime from the same PR.

[Moliholy]

Closing in favor of #295