Reactive syncing metrics

[nazar-pc]

This PR untangles syncing metrics and makes them reactive, the way metrics are supposed to be in general.

Syncing metrics were bundled in a way that caused coupling across multiple layers: justifications metrics were defined and managed by ChainSync, but only updated periodically on tick in SyncingEngine, while actual values were queried from ExtraRequests. This convoluted architecture was hard to follow when I was looking into #5333.

Now metrics that correspond to each component are owned by that component and updated as changes are made instead of on tick every 1100ms.

This does add some annoying boilerplate that is a bit harder to maintain, but it separates metrics more nicely and if someone queries them more frequently will give arbitrary resolution. Since metrics updates are just atomic operations I do not expect any performance impact of these changes.

Will add prdoc if changes look good otherwise.

P.S. I noticed that importing requests (and corresponding metrics) were not cleared ever since corresponding code was introduced in dc41558#r145518721 and I left it as is to not change the behavior, but it might be something worth fixing.

cc @dmitry-markin

[dmitry-markin]

Looks good, thank you! With updating metrics on every operation it's more difficult to check every update is handled. Hope you have searched through the code and made sure everything is covered.

[dmitry-markin]

This is out of scope of this PR, but it looks like we can legitimately hit this if the response was delivered after the peer disconnected event arrived. This can happen depending on the order different protocols/streams are polled as these events are emitted by different objects (notifications protocol for sync peers and request-response protocol for responses).

Created an issue for this: #5414.

[nazar-pc]

Hope you have searched through the code and made sure everything is covered.

I checked all occurrences and invariants and I don't think I missed anything.

[lexnv]

Would grouping the request hashmaps (or vec) with metrics help here?
Some time in the future we might do a active_requests.remove() and forget to decrement the appropriate metric.

One suggestion might be to group them into a wrapper:

struct ActiveRequestsMetered {
    inner: HashMap<..>, // Current self.active_requests
    metrics: Option<Metrics>,
}

Maybe an even simpler approach would be to introduce a fn active_requests_remove() { ...; metrics.active.dec(); }.
Could also be a followup if would take too long to implement :D

[nazar-pc]

There are several of these in the code and I'm not sure how much it would help with ergonomics to be completely honest. Metrics are one of those things that are just inherently invasive unfortunately.

[lexnv]

LGTM! Thanks for contributing!

[nazar-pc]

I resolved minor merge conflict, but also had to restore useless tick. Without this tick tests like sync::multiple_requests_are_accepted_as_long_as_they_are_not_fulfilled never finish. I didn't figure out yet what is not being polled correctly without the tick, but something just hangs in syncing engine and is never able to make it past this:

polkadot-sdk/substrate/client/network/test/src/sync.rs

Lines 1020 to 1024 in 9fecd89

	if net.peer(1).client().justifications(hashof10).unwrap() !=
	Some(Justifications::from((*b"FRNK", Vec::new())))
	{
	return Poll::Pending
	}

If someone with more knowledge in this area can take a look at it that'd be great, but it shouldn't block this PR anymore.

[nazar-pc]

CI seems to be good now