In #457 the behaviour when receiving a HEADERS frame for a new stream when fully quiesced was changed from a connection error to a stream error.

This was necessary because a client creating a new stream can race with the server sending a GOAWAY which currently results in a connect level error (which in turn typically results in the connection being closed and all in-flight requests being dropped).

However, this behaviour change should also apply to the locally quiescing state. At the moment the following can happen:

• Client sends HEADERS frame for new stream
• Server sends GOAWAY frame
• Server receives HEADERS frame for new stream
  • throws a NoSuchStreamError which is treated as a connection-level error
  • results in another GOAWAY frame with a protocolError being sent and the error being fired down the channel pipeline

ChannelHandler's reacting to errors can't distinguish between the client incorrectly implementing the protocol (i.e. a genuine NoSuchStream error) vs. a race between the server locally quiescing and the client creating a new stream.

This should instead be treated as a stream error like in #457.