bitswap: `BitSwapNetwork` notifies about connected peers that do not speak Bitswap

[Wondertan]

Here we listen and pass newly connected peers to Bitswap Client and Server. However, we do that for all our peers, including those who do not speak Bitswap protocol.

This is not a big problem because we will quickly realize that such peers are unresponsive, but we could still filter them out much earlier. This potentially warrants migrating to Identify libp2p events that now contain the list of protocols the peer supports.

[welcome[bot]]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review. In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment. Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[lidel]

@Wondertan thank you for filling this, by chance, do you have a ballpark % numbers of usable vs unusable peersyou've experienced?

cc @aschmahmann @gammazero this sounds oddly familiar, could contribute to the bitswap behavior we've seen in Rainbow traces?

[Wondertan]

We don't have any numbers yet. I realized this is an issue while exploring the code for the new protocol we are building over Bitswap. We will be running a single Server over two BitSwapNetwork and I needed to know the implications of that.

[gammazero]

When a peer connects, the peer's supported protocols are not immediately known. We may be able to wait for identify to complete before sending notification, and then see what protos are supported. Any messages from the peer will still cause a connected notification when the state changes to stateResponsive.