Update upstream to v0.9.15

[Dengjianping]

Description

Update upstream to v0.9.15

closes: #351

Calamari/Manta Runtime

Hook order execution is now more explicit hook change, The pr tells more details about the change.
For now we will use AllPalletsReversedWithSystemFirst which will preserve old behaviour and we don't have to reorder our pallets in consstruct_runtime!
At some point we should migrate to AllPalletsWithSystem - #378

Calamari/Manta Client

None.

Upstream Changes

Polkadot:

• Fix locked deposit of council voters paritytech/polkadot#4655
• Fix locked deposits of Nicks pallet  paritytech/polkadot#4656
• Fix order of hook execution paritytech/substrate#10043

paritytech/polkadot@release-v0.9.13...release-v0.9.15

Substrate:

• Fix order of hook execution paritytech/substrate#10043
• Add runtime-benchmarks for frame-benchmarking paritytech/substrate#10324

paritytech/substrate@polkadot-v0.9.13...polkadot-v0.9.15

Cumulus:
None.

paritytech/cumulus@polkadot-v0.9.13...polkadot-v0.9.15

---

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 dolphin) with right title (start with [Manta] or [Dolphin]),
• 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.
• Verify benchmarks & weights have been updated for any modified runtime logics
• If needed, bump version for every crate.
• If import a new pallet, choose a proper module index for it, and allow it in BaseFilter. Ensure every extrinsic works from front-end. If there's corresponding tool, ensure both work for each other.
• If needed, update our Javascript/Typescript APIs. These APIs are offcially used by exchanges or community developers.
• If we're going to issue a new release, freeze the code one week early(it depends, but usually it's one week), ensure we have enough time for related testing.

[stechu]

LGTM.

[stechu]

@Garandor Can you take a look whether the concern you raised is addressed? It looks to be addressed to me.

[Garandor]

My main concern is that using AllPalletsWithSystemFirst would in effect duplicate System, as it is also explicitly listed in https://github.com/Manta-Network/Manta/blob/manta/runtime/manta/src/lib.rs#L583

If system is running any hooks, its invocation could be duplicated - e.g. logs could be written twice if executed on hook.
I haven't looked into hooks enough to determine if this concern is valid or not and I will look into this more, but if any of you know this isn't a problem I would defer to your opinion.

The rest LGTM

[ghzlatarev]

My main concern is that using AllPalletsWithSystemFirst would in effect duplicate System, as it is also explicitly listed in https://github.com/Manta-Network/Manta/blob/manta/runtime/manta/src/lib.rs#L583

If system is running any hooks, its invocation could be duplicated - e.g. logs could be written twice if executed on hook. I haven't looked into hooks enough to determine if this concern is valid or not and I will look into this more, but if any of you know this isn't a problem I would defer to your opinion.

The rest LGTM

What you are looking for are the diffs in frame/executive/src/lib.rs and frame/support/procedural/src/construct_runtime/mod.rs
You can see how construct_runtime is expanded:

	let all_pallets_with_system_reversed = names
		.iter()
		.fold(TokenStream2::default(), |combined, name| quote!((#name, #combined)));

and then how it is used in Executive:

                       let on_initialize_weight =
				<AllPalletsWithSystem as OnInitialize<u64>>::on_initialize(block_number);

When before it was actually referring to system pallet explicitly:

			let frame_system_on_initialize_weight =
				frame_system::Pallet::<Runtime>::on_initialize(block_number);
			let on_initialize_weight =
				<AllPallets as OnInitialize<u64>>::on_initialize(block_number);

This is why there is no double execution. System is no longer called explicitly. but as part of the set from construct_runtime!.

[Garandor]

Ok got it, since the behavior of executive changed to not explicitly execute System, it is not a concern.

Thanks @ghzlatarev