Introduce connected_peers() API

[shamil-gadelshin]

This PR adds connected_peers API to Substrate Network (sc-network crate). The new API exports a list of the currently connected peers. It's helpful when we need to issue custom requests (libp2p request-response protocol) to some peer because the upstream protocol uses PeerId to target a specific peer. Actually, request-response protocol is able to initiate a new connection when we pass PeerId (it tries to obtain the address) but for this use-case we expose currently connected peers only.

[bkchr]

I don't get your explanation. If you only want to start_request to currently connected peers, you should use IfDisconnected::ImmediateError.

[nazar-pc]

I don't get your explanation. If you only want to start_request to currently connected peers, you should use IfDisconnected::ImmediateError.

But how do you know what peers node is connected to the first place?

[bkchr]

But how do you know what peers node is connected to the first place?

Why do you need to know? Just send to all the peers you are interested in? Also your protocol should know which peers are connected via this protocol?

[nazar-pc]

We're using it to implement #4407, Shamil should be able to provide more details once he is back online tomorrow.

[bkchr]

Then you could directly use this?

[shamil-gadelshin]

Then you could directly use this?

The link doesn't work, however, it seems you're suggesting peers_info API from syncing_engine. Although it provides networking info indirectly it might work even better because of the additional info provided (peer roles). Thanks! The downside is that the API may change with changing of the container module - syncing_engine.

Let me test that it works as expected.

[shamil-gadelshin]

peer_info API returns times less peers than connected_peers in our setup. It's likely because of the multiple peer sets that networking crates manage compared to the syncing engine. However, the provided data is enough for our use case.

Thanks for the review!