Migrate to weights V2

[svyatonik]

We'll need to migrate to this someday (my guess - before Kusama<>Polkadot bridge hub? or even for Rococo<>Wococo bridge hub?).

Right now we can't do anything because: (1) the weights PR is not merged yet (2) we are still referencing XCM v3 branch from our repo - so even if weights will be merged, we can't migrate until XCM is also merged.

paritytech/substrate#10918
paritytech/polkadot-sdk#256

[svyatonik]

There's also a limit on max POV size for parachains, which is cumulus_primitives_core::relay_chain::v2::MAX_POV_SIZE (5 * 1024 * 1024). We need to be sure that our size doesn't exceed that (verify in tests?)

[bkontur]

• search in code
  TODO: https://github.com/paritytech/parity-bridges-common/issues/1543 - check `set_proof_size` 0 or 64*1024 or 1026?

[svyatonik]

Remaining things:

• remove hack with changing max number of GRANDPA authorities in benchmarks - let's always use MaxBridgedAuthorities;
• we need to respect PoV size when building message delivery transaction - see that huge proof_size in select_delivery_transaction_limits_works test. Some other tests?;
• ensure that we are rejecting GRANDPA proofs with too-many authorities and decrease maximal number of authorities for Kusama/Polkadot/Rococo/Wococo from 100_000 (const from GRANDPA pallet config) to something much smaller;
• refund (if that is possible) unused proof_size in all calls where it is possible. Remove blocking operations in SyncProvider substrate#1853;
• maybe use PovEstimationMode::Estimated mode where appropriate?

[svyatonik]

I'm not sure about the last point (using PovEstimationMode::Estimated). E.g. if we rely on call arguments to provide this proof_size, then what if actual proof_size will be larger? We may fail the call by returning error, but the proof size will be larger than "estimated" anyway. Let's keep using MaxEncodedLen as it seems safer. But we need to impl paritytech/substrate#1853 anyway

[svyatonik]

Some TODOs are still left in code