chainHead: Track reported blocks to capture notification gaps

[lexnv]

There are cases during warp sync or re-orgs, where we receive a notification with a block parent that was not reported in the past. This PR extends the tracking state to catch those cases and report a Stop event to the user.

This PR adds a new state to the RPC-v2 chainHead to track which blocks have been reported.

In the past we relied on the pinning mechanism to provide us details if a block is pinned or not.
However, the pinning state keeps the minimal information around for pinning. Therefore, unpinning a block will cause the state to disappear.

Closes: #5761

[lexnv]

Believe that pruned_blocks are no longer needed (#5605), will tackle this in another PR

[skunert]

One downside of this approach is that we never remove anything manually and just rely on the LRU to remove items. However, that means that over time we will have the maximum amount of items in every LRU for every subscription. But in reality probably does not matter, for these 512 items thats approx. 16kb of memory usage then 🤷

[niklasad1]

I think it's quite "strange/hard to understand" use a LRU for the finalized blocks when it's treated as a FIFO queue.

Personally I would just use a fixed size ring buffer but probably less efficient to do lookups.

An alternative is create a wrapper type such as:

/// A wrapper type to utilize a LruMap as FIFO queue.
struct MostRecentFinalizedBlocks(LruMap<Block::Hash, ()>);

impl FinalizedBlocksFifo {
    fn insert(&mut self, block: Block::Hash) {
        self.finalized.insert(block, ());
     }

    fn contains(&mut self, block: &Block::Hash) -> bool {
        self.0.peek(block).is_some()
    }
}

[niklasad1]

Suggested change

	// end up with scenarios where the last inserted finalized block is removed.
	// end up with scenarios where the "finalized block" in the end of LRU is overwritten which may not necessarily be the oldest finalized block i.e, possible that "get" promotes an older finalized block because it was accessed more recently

[niklasad1]

I think it's sufficient with the comments on the struct itself to explain that the LRU is used as FIFO queue but maybe move some of the comment here to struct itself?

but up to you :)

[lexnv]

Thanks Niklas! That sounds good to me! 🙏