Fix close_write() being called too eagerly

[tomaka]

Fix #2831

The problem turned out to be very stupid:
Calling close_write() is just a shortcut for outgoing_buffer = None.
So you're supposed to call close_write() when you have nothing more to write.

The problem is that we're calling write_from_vec_deque(data), which transfers data from data to outgoing_buffer. Then we realize that data is empty (because it's been entirely copied to outgoing_buffer), and call close_write(). This sets outgoing_buffer to None and thus erases the data that we've just copied.

Instead, we now call close_write at the next iteration (when the data will have been extracted out), which is what you're supposed to do.

Additionally, as a safety measure, I've replaced close_write with close_write_if_empty. I think that close_write is too dangerous. There's never a situation where you would want to cancel sending data that you've already queued for writing.

[mergify]

Automatically approving tomaka's pull requests. This auto-approval will be removed once more maintainers are active.

[github-actions]

twiggy diff report

Difference in .wasm size before and after this pull request.

---

 Delta Bytes │ Item
─────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
         +64 ┊ smoldot::libp2p::connection::established::substream::Substream<TNow,TRqUd,TNotifUd>::read_write2::h257d3eece62d937b
         +49 ┊ smoldot::libp2p::read_write::ReadWrite<TNow>::close_write_if_empty::hebd5966bcd84121a
          +2 ┊ smoldot::libp2p::collection::multi_stream::MultiStreamConnectionTask<TNow,TSubId>::substream_read_write::hb5abbd2ac799eeef
          +1 ┊ smoldot::libp2p::collection::single_stream::SingleStreamConnectionTask<TNow>::read_write::h42c5a34b21df456e
          +1 ┊ smoldot::libp2p::connection::established::single_stream::SingleStream<TNow,TRqUd,TNotifUd>::read_write::h38cd277718fc88b9
        +216 ┊ Σ [5 Total Rows]