fix: Discard buffered DATA when a scheduled reset is pending

[ArniDagur]

A revival of #881

Implicit resets rely on pop_frame reaching the None arm to emit RST_STREAM. If DATA is queued but the stream has zero window capacity to send it, pop_frame hits this check

if sz > 0 && stream_capacity == 0 {
    tracing::trace!("stream capacity is 0");

    // The stream has no more capacity, this can
    // happen if the remote reduced the stream
    // window. In this case, we need to buffer the
    // frame and wait for a window update...
    stream.pending_send.push_front(buffer, frame.into());

    continue;
}

The frame is pushed back, but the stream is not re-enqueued until we receive a window update for it. If that update is never received, the stream reset will be delayed indefinitely (we're at the mercy of the remote). In debug builds this crashes with

panicked at src/proto/streams/counts.rs:282:13:
assertion failed: !self.has_streams()

when the connection is dropped.

fn maybe_cancel(stream: &mut store::Ptr, actions: &mut Actions, counts: &mut Counts) {
    if stream.is_canceled_interest() {
        // Server is allowed to early respond without fully consuming the client input stream
        // But per the RFC, must send a RST_STREAM(NO_ERROR) in such cases. https://www.rfc-editor.org/rfc/rfc7540#section-8.1
        // Some other http2 implementation may interpret other error code as fatal if not respected (i.e: nginx https://trac.nginx.org/nginx/ticket/2376)
        let reason = if counts.peer().is_server()
            && stream.state.is_send_closed()
            && stream.state.is_recv_streaming()
        {
            Reason::NO_ERROR
        } else {
            Reason::CANCEL
        };

        actions
            .send
            .schedule_implicit_reset(stream, reason, counts, &mut actions.task);
        actions.recv.enqueue_reset_expiration(stream, counts);
    }
}

Implicit resets can occur under three circumstances:

• CANCEL: In maybe_cancel, when all user handles are dropped for a stream that is still open
• NO_ERROR: In maybe_cancel, when all user handles are dropped for a server stream where the response is already queued
• PROTOCOL_ERROR: From the oversized headers path in streams.rs, after a rejection response is sent

For context, NO_ERROR for a stream reset is only supposed to be sent after a complete response. Buffering data + response, and then dropping the stream handles sounds like a relatively normal thing to do, and I think we want to support it.

However, for the other cases we should just fast-track stream reset and delete the buffered data, as we don't care about the stream anymore. Sending it would be wasteful.