Create invalid extrinsics fraud proof storage, and move block randomness into it

[teor2345]

This PR:

• creates a common InvalidInherentExtrinsicData fraud proof storage, and
• moves the extrinsics_shuffling_seed derived from block_randomness into it

It also fixes some typos, and simplifies some of the code.

Part of #3281.

Eventually, all of InvalidInherentExtrinsicProof and most of DomainInherentExtrinsicData (except the sudo call) will be moved into InvalidInherentExtrinsicData.

Code contributor checklist:

• I have read, understood and followed contributing guide

[NingLin-P]

Rest LGTM

[NingLin-P]

Rest LGTM

[NingLin-P]

This field was introduced recently and is not exist in the consensus runtime in mainnet, so we should also remove it

[teor2345]

Specifically in #3312, where it wasn’t caught in review. Is there an automated test we could add to catch accidental changes like this?

[NingLin-P]

It is hard to test compatibility with an existing network in unit/integration test, usually we will test runtime upgrade before release (by simulating the existing network in a local network).

[teor2345]

Hang on, is this a breaking runtime API change?

This enum is passed to a runtime API here:

subspace/crates/sp-domains-fraud-proof/src/lib.rs

Lines 157 to 166 in 5675113

	sp_api::decl_runtime_apis! {
	/// API necessary for fraud proof.
	pub trait FraudProofApi<DomainHeader: HeaderT> {
	/// Submit the fraud proof via an unsigned extrinsic.
	fn submit_fraud_proof_unsigned(fraud_proof: FraudProof<NumberFor<Block>, Block::Hash, DomainHeader, H256>);
	/// Reture the storage key used in fraud proof
	fn fraud_proof_storage_key(req: FraudProofStorageKeyRequest<NumberFor<Block>>) -> Vec<u8>;
	}
	}

If it is, I think we'll need to bump the runtime version in this PR as well.

Edit: Or since it already got bumped in #3303, maybe that's ok.

[NingLin-P]

This should be fine as runtime API only fail when we actually call it and it has never been called yet as there is no domain initialized (while the host function change will crash the node upon runtime/client upgrade).

[teor2345]

Yep, in this case it would produce wrong results (because enum variants have changed indexes) or fail (because the expected data does not accompany the variant at that index). So that’s fine as long as most nodes are upgraded before then.

We might want to bump the runtime version for Taurus though.

[NingLin-P]

This should be fine as runtime API only fail when we actually call it and it has never been called yet as there is no domain initialized (while the host function change will crash the node upon runtime/client upgrade).

[NingLin-P]

It is hard to test compatibility with an existing network in unit/integration test, usually we will test runtime upgrade before release (by simulating the existing network in a local network).