cli: tunnels can sporadically become unresponsive

[connor4312]

Last iteration I moved some RPC logic to use Tokios "codecs" to give
them cancellation safety. These operate on streams of input data.

While this worked at first, I failed to take into account that the byte
buffer we read from the stream could have more data than just the
current message under load scenarios. We were discarding any extra data
from the subsequent message. In most cases caused the next message
"length" to be read from the middle of the next message, which usually
(when parsed as a u32) was some number of gigabytes, then causing the
connection to stall forever.

Fixes #181284

[aeschli]

Testing the fix by running from sources

• starting the tunnel from the Code OSS, Account menu
• opening the tunnel in vscode.dev with the link given by the notification

Without the fix, vscode.dev is not not showing any files in the file explorer, it's idling and can't connect to the tunnel. With the fix, loading works, but

• initial loading takes a long time. It takes almost a minute until the server reports that a client connection has been opened. Once that happens, all loads fine. Files can be accesssed
• however, when reloading, in no longer can show the folder. Server log shows error handshaking session for all client connections

2023-05-02 12:22:13.387 [info] [2023-05-02 12:22:13] info [tunnels::connections::relay_tunnel_host] Opened new client on channel 51

2023-05-02 12:22:13.408 [info] [2023-05-02 12:22:13] error [tunnels::connections::relay_tunnel_host] error handshaking session: EOF

[aeschli]

Using bisect on insiders builds, it looks like the reload bug is present even in 1.77 insiders.
Created #181319