[Manta-PC] Updrading dependencies to v0.9.10

[ghzlatarev]

Description

closes: #196

Polkadot Changes:

• release v0.9.10 pr set1 paritytech/polkadot#3763
• v0.9.10-rc3 - Updated weights and transaction_version paritytech/polkadot#3865
• demote warnings due to disconnected dispute coordinator paritytech/polkadot#3672
• Bypass chain-selection subsystem until disputes are enabled. paritytech/polkadot#3676
• properly gate sanity check paritytech/polkadot#3684
• bump version and spec_version fro 0.9.10 paritytech/polkadot#3761
  Overview PR:
• Polkadot v0.9.10 Release checklist paritytech/polkadot#3760

Substrate Changes:

• Fixed block response limit check paritytech/substrate#9692
• Fix compact proof decoding unaccessed last child trie.  paritytech/substrate#9715
• Cherry Pick of PR #9676 + #9391 paritytech/substrate#9704
• Add PR #9442 for 0.9.10 paritytech/substrate#9767
• Backports for 0.9.10 paritytech/substrate#9845
• No overview PR

Cumulus Changes:

• Support XCM v1 (Companion to #2815) paritytech/cumulus#561
• Use new MultiLocation syntax everywhere paritytech/cumulus#570
• paritytech/cumulus@fa116cf
• No overview PR

statemine diffs between:

• fd80849dde5c209c20a996cfcc5aaacd4666dcbe -> 0.9.9
• fa116cfbfb470a8114fc02f9d2e3c0a5ab6c7193 -> 0.9.10

Performed tests with local calamari-local and calamari-testnet networks:

• Does key injection script work (only for calamari-testnet)
• Check block production
• Sudo system.setCode upgrade
• Force transfer balances
• Pass sudo to multi-sig account
• Upgrade with authorizeUpgrade + enactAuthorized
• Check average block time is ~12 seconds
• Check dropping and reconnecting a collator

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (manta or manta-pc) with right title (start with [Manta] or [Manta-PC]),
• Linked to Github issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• Wrote unit tests.
• Updated relevant documentation in the code.
• Re-reviewed Files changed in the Github PR explorer.
• If runtime changes, need to update the version numbers properly:
  • authoring_version: The version of the authorship interface. An authoring node will not attempt to author blocks unless this is equal to its native runtime.
  • spec_version: The version of the runtime specification. A full node will not attempt to use its native runtime in substitute for the on-chain Wasm runtime unless all of spec_name, spec_version, and authoring_version are the same between Wasm and native.
  • impl_version: The version of the implementation of the specification. Nodes are free to ignore this; it serves only as an indication that the code is different; as long as the other two versions are the same then while the actual code may be different, it is nonetheless required to do the same thing. Non-consensus-breaking optimizations are about the only changes that could be made which would result in only the impl_version changing.
  • transaction_version: The version of the extrinsics interface. This number must be updated in the following circumstances: extrinsic parameters (number, order, or types) have been changed; extrinsics or pallets have been removed; or the pallet order in the construct_runtime! macro or extrinsic order in a pallet has been changed. If this number is updated, then the spec_version must also be updated
• If needed, notify the committer this is a draft-release and a tag is needed after merging the PR.

[ghzlatarev]

@stechu reverted the chain_spec version to 1. We will need a runtime upgrade after Kusama has done one, as per what Basti said.

[ghzlatarev]

@stechu triggered the integration tests with a fake tag namev0.0.0-polkadot-v0.9.9-tests
We will need a real one when you merge this.

[stechu]

@stechu reverted the chain_spec version to 1. We will need a runtime upgrade after Kusama has done one, as per what Basti said.

I am not sure whether this alone will do that job. In the code, you still rely on the new version of XCM. I would suggest you to roll-back the XCM related code, i.e. still use v0.

[stechu]

@ghzlatarev As we discussed, can you provide the list of upstream changes that we can review against to?

[ghzlatarev]

@ghzlatarev As we discussed, can you provide the list of upstream changes that we can review against to?

My bad included it in the description.
polkadot -> release-v0.9.10 -> https://github.com/paritytech/polkadot/releases/tag/v0.9.10-rc2
Cumulus diff between:
fd80849dde5c209c20a996cfcc5aaacd4666dcbe -> 0.9.9
fa116cfbfb470a8114fc02f9d2e3c0a5ab6c7193 -> 0.9.10

[ghzlatarev]

@stechu reverted the chain_spec version to 1. We will need a runtime upgrade after Kusama has done one, as per what Basti said.

I am not sure whether this alone will do that job. In the code, you still rely on the new version of XCM. I would suggest you to roll-back the XCM related code, i.e. still use v0.

I don't seem to be able to make the runtime code compile without using v1 folder yet.

[Dengjianping]

@stechu Do you think we need to bump the version as well? From 3.0.1 to 3.0.2.

[stechu]

@stechu Do you think we need to bump the version as well? From 3.0.1 to 3.0.2.

We should.

[stechu]

@stechu reverted the chain_spec version to 1. We will need a runtime upgrade after Kusama has done one, as per what Basti said.

I am not sure whether this alone will do that job. In the code, you still rely on the new version of XCM. I would suggest you to roll-back the XCM related code, i.e. still use v0.

I don't seem to be able to make the runtime code compile without using v1 folder yet.

[stechu]

@ghzlatarev As we discussed, can you provide the list of upstream changes that we can review against to?

My bad included it in the description.
polkadot -> release-v0.9.10 -> https://github.com/paritytech/polkadot/releases/tag/v0.9.10-rc2
Cumulus diff between:
fd80849dde5c209c20a996cfcc5aaacd4666dcbe -> 0.9.9
fa116cfbfb470a8114fc02f9d2e3c0a5ab6c7193 -> 0.9.10

@ghzlatarev Here is an example of how to properly description a upstream upgrade:

Polkadot Changes:

The list of polkadot changes

• demote warnings due to disconnected dispute coordinator paritytech/polkadot#3672
• Bypass chain-selection subsystem until disputes are enabled. paritytech/polkadot#3676
• properly gate sanity check paritytech/polkadot#3684
• bump version and spec_version fro 0.9.10 paritytech/polkadot#3761

Overview PR:
paritytech/polkadot#3763

Please do the same for Cumulus and Substrate.

[ghzlatarev]

Substrate Changes:

• Fixed block response limit check paritytech/substrate#9692
• Fix compact proof decoding unaccessed last child trie.  paritytech/substrate#9715
• Cherry Pick of PR #9676 + #9391 paritytech/substrate#9704
• Add PR #9442 for 0.9.10 paritytech/substrate#9767
• Backports for 0.9.10 paritytech/substrate#9845
• No overview PR

Cumulus Changes:

• Support XCM v1 (Companion to #2815) paritytech/cumulus#561
• Use new MultiLocation syntax everywhere paritytech/cumulus#570
• paritytech/cumulus@fa116cf
• No overview PR

statemine diffs between:

• fd80849dde5c209c20a996cfcc5aaacd4666dcbe -> 0.9.9
• fa116cfbfb470a8114fc02f9d2e3c0a5ab6c7193 -> 0.9.10

[ghzlatarev]

@stechu Do you think we need to bump the version as well? From 3.0.1 to 3.0.2.

We should.

Done.

[Dengjianping]

LGTM!