fix(hole-punch): don't explicitly close RESERVE stream

Making a reservation on a relay involves a request-response protocol. First we send the `RESERVE` message and then we receive the relay's response. After we've received the response, we have all the information we need and the reservation is valid.

It appears that on QUIC, closing the stream can fail if the other party also closed the stream already. This can result in the entire operation failing at the very end even though everything else has succeeded.

There is no reason to explicitly close the stream as the remote is not going to read from it beyond the first message anyway. The fact that we receive a response means the remote read our request.

This should resolve some of the flakiness that we've been seeing with the hole-punch interop tests.

Pull-Request: #4747.

Author: thomaseizinger

protocols/relay/CHANGELOG.md

@@ -1,5 +1,8 @@
 ## 0.17.0 - unreleased
 
+- Fix a rare race condition when making a reservation on a relay that could lead to a failed reservation.
+  See [PR 4747](https://github.com/libp2p/rust-lib2pp/pulls/4747).
+
 ## 0.16.2
 
 ## 0.16.1

protocols/relay/src/protocol/outbound_hop.rs

@@ -171,8 +171,6 @@ pub(crate) async fn handle_reserve_message_response(
         .map(Delay::new)
         .ok_or(FatalUpgradeError::InvalidReservationExpiration)?;
 
-    substream.close().await?;
-
     Ok(Ok(Reservation {
         renewal_timeout,
         addrs,