Parachain commander: publish finality lag

[Andrei Sandu]

In #181 we added support for selecting to which block stream we subscribe. In order to compute finality lag we should follow both finalized and best streams but the processing of blocks should be done as configured in the CLI

[Andrei Eres]

Some notes

relay chain finality lag = best block number - last finalized block number

this functionality could best live in the collector, parachain commander would just display it.

we can compute finality lag at each best block and put that into storage

async fn process_new_head(&mut self, block_hash: H256) -> color_eyre::Result<()> — puts block header in storage

we could change the storage entry to also contain the finality lag or it is far better to have just the last finalized block

from Parachain commander we just read the storage and get that info

[Andrei Eres]

@sandreim @vstakhov
Because the implementation causes tons of inner changes, I'd rather split it for few pull requests. The main idea is to move block and events handling to the collector. Then we can remove the best/finalized mode from subxt subscription and start receiving both block types and forward them to the collector. In the collector, we can extract all the needed data from blocks and produce events according to the best/finalized mode.

Steps

• Move block events mapping to collector
• Start to receive both block types from subxt and handle it in the collector
• Add the lag calculation

[Andrei Sandu]

@sandreim @vstakhov Because the implementation causes tons of inner changes, I'd rather split it for few pull requests.

This makes sense to me!

The main idea is to move block and events handling to the collector. Then we can remove the best/finalized mode from subxt subscription and start receiving both block types and forward them to the collector. In the collector, we can extract all the needed data from blocks and produce events according to the best/finalized mode.

This is similar to what I had in mind.