Remove some multistream-select round-trips (#2984)

cc #2983

This PR removes some extra networking round-trips caused by
multistream-select.

The way multistream-select works is: we tell the remote that we would
like to use a specific protocol, and then the remote answers either yes
or no. No is only ever returned if the remote doesn't support the
protocol at all, which isn't supposed to happen unless we're talking to
a buggy node or to a libp2p-compatible-but-not-Substrate node.
Before this PR, we wait for the remote to send back yes or no. After
this PR, we don't wait and simply start sending the protocol-specific
data immediately after the request for a protocol, and assume that the
remote is going to answer yes.

The negotiation is still properly finished afterwards, so if it turns
out that the remote answers no, then we'll still get an error locally.
The drawback is that, if the remote answers no, the protocol-specific
data that we have eagerly sent will be interpreted as being from the
multistream-select protocol, which can lead to confusing decoding
errors. However, the trade-off is worth it.

I've done this change only for substreams after the connection has been
opened. There are two other unnecessary round-trips during the
connection opening, but considering that we don't open connections that
often they're actually less important. For this reason, I'll leave
#2983 open.

Co-authored-by: mergify[bot] <37929162+mergify[bot]@users.noreply.github.com>

bin/wasm-node/CHANGELOG.md

@@ -2,6 +2,10 @@
 
 ## Unreleased
 
+### Changed
+
+- Reduced the number of networking round-trips after a connection has been opened by assuming that the remote supports the desired networking protocols instead of waiting for its confirmation. ([#2984](https://github.com/paritytech/smoldot/pull/2984))
+
 ## 0.7.6 - 2022-11-04
 
 ### Fixed