Send CONNECTION_CLOSE as a client if the server closes the connection during the handshake

[matheus23]

There are two places that handle receiving CONNECTION_CLOSE frames in Quinn.

This is in process_early_payload (called during the handshake):

quinn/quinn-proto/src/connection/mod.rs

Lines 2482 to 2486 in 76020ba

	if let Frame::Close(_) = frame {
	trace!("draining");
	self.state = State::Draining;
	break;
	}

This is in process_payload (outside the handshake):

quinn/quinn-proto/src/connection/mod.rs

Lines 3072 to 3076 in 76020ba

	if let Some(reason) = close {
	self.error = Some(reason.into());
	self.state = State::Draining;
	self.close = true;
	}

The former doesn't actually queue a CONNECTION_CLOSE frame when it receives one.
This seems weird to me, as this breaks graceful close during handshakes.
I.e. if the server closes the connection during the handshake, the client will receive that CONNECTION_CLOSE, but not respond with one of its own, leaving the server hanging. Thus the server ends up draining the connection for longer than might be strictly necessary, keeping state around for 3 * PTO.

[Ralith]

This is not a bug; per RFC, it looks to me like either behavior is conformant. However, I can't think of a reason why we shouldn't send a close during the handshake, so I'm not opposed to that being changed. I think you meant to refer to this code, though:

quinn/quinn-proto/src/connection/mod.rs

Lines 2738 to 2742 in 76020ba

	Frame::Close(reason) => {
	self.error = Some(reason.into());
	self.state = State::Draining;
	return Ok(());
	}

[matheus23]

From looking at msquic test logs, it seems like msquic also doesn't reciprocate CONNECTION_CLOSE when it happens during the handshake.

Quinn also doesn't "expect" a connection close to be reciprocated necessarily. Changing the client to reciprocate it makes the validate_then_reject_manually test flaky (25% of the time). This is because the server side rejects the packet with quinn_proto::Endpoint::refuse, which doesn't store any state about the Incoming, and the client sending back a CONNECTION_CLOSE can be interpreted as yet another Incoming on the server side (in 25% of the cases).

I write more about this in n0-computer/noq#718 and I'm actually not super sure about how to solve this. I'd personally quite like to, because it gets rid of a case where the server is kept idle in the closing state by the client's lack of a reciprocal CONNECTION_CLOSE, but besides that there's no compliance reason to change the behavior.