STOP_SENDING support

[rakbladsvalsen]

Hi! I see that there's basic support for this kind of frame. It appears to be handled, but it doesn't seem to fire any events back to the user, it just gets "processed" away by _handle_stop_sending_frame but that's it.

I didn't test this thoroughly but it seems that even if the remote peer sends us a STOP_SENDING frame we're still able to send data on the same stream_id. From what I've read, some QUIC implementations will send back a STREAM_RESET once they receive a STOP_SENDING frame. 1

I half-implemented this missing feature (literally QuicConnection.stop_sending(stream_id, error_code) so I could send this frame) and even though I'm able to properly send the frame it just gets ACK'd away. I indeed confirmed this by analyzing the traffic with wireshark and yeah, it is just ACK'd without anything changing internally.

I have a question (not related to this issue). Are there any plans to make this library any faster? I noticed that there are quite a lot of simple data classes, which we could probably rewrite using ctypes. We could port the whole thing to Cython. If you have any future plans to do so I'm in.

[sethmlarson]

Also throwing mypyc into the ring of potential speedup routes.