Upgrade to stable2412-2

[dastansam]

What?

closes #446

Tasks

• Review release notes for stable2412 for breaking changes. Also check the release notes of the versions before (with a focus on stable2409 and 1.14.0).
• Update Polkadot SDK dependencies to stable2412.
• Update ORML dependencies to the according version.
• Test node and runtime compatibility (e.g., compile-time errors, runtime APIs, storage migrations).
• Audit custom pallets for deprecated or changed SDK interfaces.
• Update benchmarks (if applicable) for weight calculations.

Additional Context

• The Treasury::propose_spend(...) integrations tests needs a rework, since that extrinsic is now deprecated, and it should be replaced by Treasury::sped_local(...). We can ignore these tests for now and re-add them in a later PR.

Why?

Release analysis posts here.

Some notable PRs:

• Replaces SignedExtra with new TransactionExtension. This requires us to reimplement the custom CheckNonce as a follow up PR - FRAME: Reintroduce TransactionExtension as a replacement for SignedExtension paritytech/polkadot-sdk#3685
• XCM V5 is now latest, so v4 xcm types are replaced with v5 - XCM v5 paritytech/polkadot-sdk#4826 -
• merges xcm-fee-payment-runtime-api module into the new xcm-runtime-apis - [xcm] runtime api for LocationToAccount conversions paritytech/polkadot-sdk#4857
• remove sp-std dependency, replace with alloc or core

How?

Testing?

• Pallet Unit Testing (e.g. cargo t -p pallet-funding)
• Integration Tests (e.g. cargo t -p integration-tests)
• Try Runtime CLI, to test if we have to run any migration in this upgrade.

Screenshots (optional)

Syncing with mainnet `polimec`

[dastansam]

• Vesting pallet block number provider migration #474
• Linear release block number provider migration #473
• Funding pallet migration for enabling async backing #472
• Prepare pallets for async backing #471
• Upgrade to stable2412-2 #470 👈 (View in Graphite)
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

[lrazovic]

A few minor nits, but overall looks quite good! I'm just a bit worried about this entire XCMv5, maybe a bit "premature" since AH is still not using it. Do you think it is a good idea to proceed with the update? Can we stick to XCMv4 for now and move to v5 after AH also migrates to v5?