CheckBridgedBlockNumber signed extension to reject duplicate header-submit transactions

[svyatonik]

related to #1162 (we'll need a couple of other extensions to close the issue)

Things to do:

• actually test it;
• think about adding BestBlockNumber storage entry (or changing existing BestFinalized to store both block hash and number) to the grandpa pallet. This would allow us to use single storage read instead of two when validating. This needs to be done carefully (in a separate PR), because it may break existing deployments, which will need an upgrade in this case. UPD: extracted to Store best finalized header id (hash + number) instead of just hash in bridge-grandpa pallet #1368;
• is there any other way than using macro to declare runtime-specific extension? Static type map or something like that? Maybe some existing macro. UPD: why do we need macro at all, instead of introducing multiple extensions - i.e. CheckBridgedBlockNumber<Runtime, WestendGrandpaInstance> and CheckBridgedBlockNumber<Runtime, RialtoGrandpaInstance>? That's because every extension has associated IDENTIFIER const, which has to be unique. The outcome of not being unique, iirc is invalid metadata. We could use adt_const_params rust feature if we were on nightly, but we are not. So the only solution I see now, is to have this single, multi-instance extension that can only be created using macro (as I said before - worth exploring).

Update related to last checkbox - I was thinking that possibly using impl_for_tuples would help. So something like:

trait FilterCall<Call> {
  fn is_valid(call: &Call) -> Option<bool>;
}

// implement `FilterCall` for Pallet<T, I> and for tuples, so we could use something like `(WithWestendGrandpa, WithRialtoGrandpa)`

type SignedExtension = SignedExtension<(WithWestendGrandpa, WithRialtoGrandpa)>;

But I've found no way to match (and deconstruct) runtime call when you're at pallet level. So given runtime call, but no knowledge of runtime, I can't do match inside FilterCall::is_valid. So I see no other option, but to use macro for now.

[svyatonik]

Merging with deferred review

[serban300]

Related to:

* [x]  is there any other way than using macro to declare runtime-specific extension? Static type map or something like that? Maybe some existing macro. UPD: why do we need macro at all, instead of introducing multiple extensions - i.e. `CheckBridgedBlockNumber<Runtime, WestendGrandpaInstance>` and `CheckBridgedBlockNumber<Runtime, RialtoGrandpaInstance>`? That's because every extension has associated `IDENTIFIER` const, which has to be unique. The outcome of not being unique, iirc is invalid metadata. We could use `adt_const_params` rust feature if we were on nightly, but we are not. So the only solution I see now, is to have this single, multi-instance extension that can only be created using macro (as I said before - worth exploring).

Update related to last checkbox - I was thinking that possibly using impl_for_tuples would help. So something like:

trait FilterCall<Call> {
  fn is_valid(call: &Call) -> Option<bool>;
}

// implement `FilterCall` for Pallet<T, I> and for tuples, so we could use something like `(WithWestendGrandpa, WithRialtoGrandpa)`

type SignedExtension = SignedExtension<(WithWestendGrandpa, WithRialtoGrandpa)>;

But I've found no way to match (and deconstruct) runtime call when you're at pallet level. So given runtime call, but no knowledge of runtime, I can't do match inside FilterCall::is_valid. So I see no other option, but to use macro for now.

We might be able to match the call with something like:

fn validate<T: Config<I>, I: 'static + Callable<T, Call = crate::Call<T, I>>>(call: T::Call)
where
	T::Call: IsSubType<CallableCallFor<I, T>>,
	<T as pallet_bridge_grandpa::Config<T::BridgesGrandpaPalletInstance>>::BridgedChain:
		bp_runtime::Chain<
			BlockNumber = RelayBlockNumber,
			Hash = RelayBlockHash,
			Hasher = RelayBlockHasher,
		>,
{
	if let Some(crate::Call::<T, I>::submit_parachain_heads {
		ref at_relay_block,
		ref parachains,
		..
	}) = call.is_sub_type()
	{}
}

This example is for parachains but it can be adapted for the grandpa pallet. I will do some experiments these days to see if it works.

[serban300]

The PR looks good and the comment related to reducing the number of macros has been addressed as part of #1519 . Marking the PR as reviewed.