substream: Investigate incorrect termination of connection on fragmented reads

[lexnv]

There is a potential bug in the Stream implementation of the litep2p Substream object.

The poll_next implementation can terminate the substream incorrectly / abruptly.

This can happen on fragmented reads using the ProtocolCodec::Identify protocol:

• Presume we want to read 1024 from the network
• The OS delivered the TCP reads in two chunks of 512 bytes

• litep2p/src/substream/mod.rs

  Line 539 in b16c74c

  match futures::ready!(poll_read!(&mut this.substream, cx, &mut read_buf)) {

• The first read sets the nread to 512
• The second read sets the nread to 512
• At this point, we are comparing 512 with 1024, which is wrong, because we have drained from the OS socket 1024 bytes in total:

litep2p/src/substream/mod.rs

Line 551 in b16c74c

if nread == payload_size {

At the next point, the socket may return 0, and we'll terminate the connection immediately.

Discovered during:

• [ElasticScaling] Enable ElasticScaling on AHKusama and AHPolkadot polkadot-sdk#10425