roadmap: rewrite the section about efficient handshakes (#461)

* roadmap: rewrite the section about efficient handshakes

* fix typos

Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Prithvi Shahi <50885601+p-shahi@users.noreply.github.com>

Co-authored-by: Max Inden <mail@max-inden.de>
Co-authored-by: Prithvi Shahi <50885601+p-shahi@users.noreply.github.com>

Author: 3 people

ROADMAP.md

@@ -321,21 +321,19 @@ be achieved with the [WebTransport](#✈️-webtransport) protocol.
 **High priority for: IPFS**
 
 **What?** Establishing a connection and performing the initial handshake
-should be as cheap and fast as possible. Supporting things like
-*selective* stream opening, *preemption*, *speculative* negotiation,
-*upfront* negotiation, protocol table *pinning*, etc. may enable us to
-achieve lower latencies when establishing connections, and even the
-0-RTT holy grail in some cases. These features are being discussed in
-the *Protocol Select* protocol design.
-
-**Why?** Multistream 1.0 is chatty and naïve. Streams are essential to
-libp2p, and negotiating them is currently inefficient in a number of
-scenarios. Also, bootstrapping a multiplexed connection is currently
-guesswork (we test protocols one by one, incurring in significant
-ping-pong).
+should be as cheap and fast as possible. On TCP, the current libp2p
+handshake spends one round-trip negotiating the security protocol, and
+another round-trip negotiating the stream multiplexer.
+By using advanced features of the handshake protocol, we might even be
+able to reach the holy grail of a 0-RTT handshake in some cases.
+
+**Why?** Applications rely on quick connection establishment. libp2p
+shouldn't make them wait for any longer than absolutely necessary.
 
 **Links:**
 
+- [Security protocol in multiaddr](https://github.com/libp2p/specs/pull/353)
+- [Muxer selection in security handshake](https://github.com/libp2p/specs/pull/446)
 - [Protocol Select specification](https://github.com/libp2p/specs/pull/349)
 
 ### 🛣️ Peer Routing Records