webrtc: handle optimistic peer during multistream-select handshake

[gab8i]

As explained here (#573 (comment)), the current multistream-select handshake doesn't handle the case where the peer is optimistic and also sends the first channel message right after the protocol reply.

Currently there is just a warning, and the trailing bytes after the multistream-select messages are discarded. They should instead be propagated back and handled within the state machine as an incoming message for the next phase after the handshake.

[gab8i]

Am I wrong or #594 also tangentially address this? Not sure if all the code is in place, but the scaffolding created by the PR should be used within the handshake protocol to handle optimistic peers

[gab8i]

After a little check, #594 built the right scaffolding (per-channel buffering + sequential frame dispatch) and solved the frame-level issue. What remains is the payload-level case: register_response should return any remaining bytes after HandshakeResult::Succeeded so on_outbound_opening_channel_data can do whatever needed to feed them to the newly opened substream. One possibility would be to send back the the trailing bytes within the HandshakeResult::Succeeded(protocol, maybe_trailing_bytes) variant and re-encode them within recv_buffers so that on the next iteration it will just be treated as another webrtct message that will properly be dispatched to the opened channel.

Does this approach makes sense or am I not seeing an obvious problem into re-inserting the trailing bytes as message? @lexnv

[lexnv]

That makes sense, I would maybe tackle this issue towards the end of the milestone since it has a lower prio 🙏