Streams receiving peer reset clear pending send (#238)

Because streams that were being peer reset were not clearing pending
send frames / buffered_send_data, they were not being counted towards
the concurrency limit.

src/proto/streams/prioritize.rs

@@ -555,6 +555,9 @@ impl Prioritize {
         while let Some(frame) = stream.pending_send.pop_front(buffer) {
             trace!("dropping; frame={:?}", frame);
         }
+
+        stream.buffered_send_data = 0;
+        stream.requested_send_capacity = 0;
     }
 
     fn pop_frame<B>(
@@ -574,6 +577,14 @@ impl Prioritize {
                 Some(mut stream) => {
                     trace!("pop_frame; stream={:?}", stream.id);
 
+                    // If the stream receives a RESET from the peer, it may have
+                    // had data buffered to be sent, but all the frames are cleared
+                    // in clear_queue(). Instead of doing O(N) traversal through queue
+                    // to remove, lets just ignore peer_reset streams here.
+                    if stream.state.is_peer_reset() {
+                        continue;
+                    }
+
                     // It's possible that this stream, besides having data to send,
                     // is also queued to send a reset, and thus is already in the queue
                     // to wait for "some time" after a reset.