Destroying connections should use `reasonToCode` for code when rejecting new streams

[tegefaulkes]

Specification

In the QUICConnection.processStreams, in the case where the connection is in the process of destroying. Any new streams that are iterated over are immediately shut down with code 1. We shouldn't be hard coding this code. We should pass in a relevant quic error into ReasonToCode and use the code provided by that function.

Additional context

Tasks

• 1. Use the reasonToCode method to determine the code used when rejecting new connections during destroy.

[tegefaulkes]

There are 3 places where the streamShutdown code is hard-coded. 2 places in processStreams where it processes the readable and writable streams. and when the connection aborts waiting for secure establishment.

The fix is to get the code from reasonToCode while providing it a relevant error. The question is, what to call these errors?

The error for failing to connect should be different from the draining state error. I'm thinking

1. Failing to establish will use whatever the abortion reason is.
2. Rejecting when the connection is closing could be the existing ErrorQUICConnectionNotRunning error or a new ErrorQUICConnectionStopping error.

[CMCDragonkai]

So QUIC library won't know what exactly these codes or reasons should be unless it's indeed "system" specific. In all other cases it should be setup by the application - that being Polykey library.