Extend EthereumBlockNotification with reorg info to allow compliance with Ethereum specs

[manuelmauro]

Description

Modify the EthereumBlockNotification struct in fc-mapping-sync to include reorg information. The mapping sync layer already tracks the canonical chain and could provide this data.

Implementation:

// In fc_mapping_sync
pub struct EthereumBlockNotification<B: BlockT> {
    pub hash: B::Hash,
    pub is_new_best: bool,
    pub reorg_info: Option<ReorgInfo>, // NEW
}

pub struct ReorgInfo {
    pub retracted: Vec<B::Hash>,
    pub enacted: Vec<B::Hash>,
}

This allows us to comply with Ethereum specs.

[manuelmauro]

This is (kind of) a follow-up PR to #1781

[manuelmauro]

@RomarQ concerning the comments above, the fact that we populate the reorg info at Canonicalize-time should guarantee their soundness, right?

Specifically this:

let reorg_info = if let Some(ref tree_route) = notification.tree_route {
	log::debug!(
		target: "frontier-sql",
		"🔀  Re-org happened at new best {}, proceeding to canonicalize db",
		notification.hash
	);
	let retracted = tree_route
		.retracted()
		.iter()
		.map(|hash_and_number| hash_and_number.hash)
		.collect::<Vec<_>>();
	let enacted = tree_route
		.enacted()
		.iter()
		.map(|hash_and_number| hash_and_number.hash)
		.collect::<Vec<_>>();

	let common = tree_route.common_block().hash;
	tx.send(WorkerCommand::Canonicalize {
		common,
		enacted: enacted.clone(),
		retracted: retracted.clone(),
	}).await.ok();

	Some(ReorgInfo {
		common_ancestor: common,
		retracted,
		enacted,
	})
} else {
	None
};

[RomarQ]

I am a bit concerned that the notification mechanism for key-value and sql backends are so different. Could we unify the notification mechanism in a single place? maybe reusing the WorkerCommand approach.

We also need to run the test for each storage backend sql and key-value.

[manuelmauro]

I am a bit concerned that the notification mechanism for key-value and sql backends are so different. Could we unify the notification mechanism in a single place? maybe reusing the WorkerCommand approach.

We also need to run the test for each storage backend sql and key-value.

Possibly addressed the comment in dbd0537 and 4582a9a

(It might need more work.)

[RomarQ]

Currently, the implementation of kv and sql backends seems to different. This makes the maintenance more difficult and can cause inconsistencies. I think we should try to align the mapping-sync implementation on both backends, by making it more generic.

I am fine to approve this once the remarks have been addressed, and do the alignment of the mapping-sync implementation in a follow-up PR.