Wake the task up when inserting a new response into PendingResponses

[dmitry-markin]

This is a hot fix for #1650. Basically, StreamMap suffers from the same footgun as FuturesUnordered: it must be explicitly polled in order for a newly added stream to be registered in the task. The streams are just pushed into the internal container upon insertion: https://github.com/tokio-rs/tokio/blob/master/tokio-stream/src/stream_map.rs#L445-L453

This PR adds a Waker to PendingResponses to make sure the task is woken up when a new response is added.

[paritytech-cicd-pr]

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: cargo-clippy
Logs: https://gitlab.parity.io/parity/mirrors/polkadot-sdk/-/jobs/3827638

[altonen]

I think in general it would be good to test all non-trivial networking changes on a live node since the test coverage of sc-network has proven to be insufficient

[bkchr]

This requires that we called poll before. Not sure that this is removing any footgun.

[bkchr]

Looking at the code we are already polling pending_responses after we inserted any kind of element, so why is the task not waking up?

[dmitry-markin]

This requires that we called poll before. Not sure that this is removing any footgun.

Yeah, but we definitely called it at least once.

[dmitry-markin]

Looking at the code we are already polling pending_responses after we inserted any kind of element, so why is the task not waking up?

There is no problem with waking up right now, but it can shoot us once the polling in SyncingEngine is converted into select! and the order of inserting / polling pending_responses is not strictly defined.

[bkchr]

But for a select!. Once you insert data to the pending_responses your match arm will be finished and you start again from the top of the loop, aka calling select! again. This will poll all futures, including your pending_responses futures. So, not sure why we could miss there to poll it.