In #105 we added the ability to defer sending reset due to how the nghttp2 library API works (see nghttp2/nghttp2#692).

This mechanism does not work well in the client case where we may be waiting to send request data, timeout, reset the stream, but then actually sit around in the codec and wait for the stream to complete sending before we reset it.

We either need to change how the deferral mechanism works so that if we haven't sent a reset by the time the pending frames are flushed, we send one at that time, or we will need to differentiate between the different kinds of resets, and potentially use a cancel error code to mean "reset this stream now even if we drop pending frames."