ATS closes an H2 connection after refusing a new stream on the connection

If ATS send RST_STREAM for some reasons right after receiving HEADERS frame from a client, following frames (CONTINUATION, DATA, etc) from the client cause an H2 connection error which leads to connection close.

According to the spec we have two options:
- Ignore following frames
- Treat it as being in error AFTER some time
```
If this state is reached as a result of sending a RST_STREAM
frame, the peer that receives the RST_STREAM might have already
sent -- or enqueued for sending -- frames on the stream that
cannot be withdrawn. An endpoint MUST ignore frames that it
receives on closed streams after it has sent a RST_STREAM frame.
An endpoint MAY choose to limit the period over which it ignores
frames and treat frames that arrive after this time as being in
error.
```
https://tools.ietf.org/html/rfc7540#section-5.1

Currently, ATS treat it as in error immediately after sending RST_STREAM frame. Because following frames are sent right after HEADERS frame in most cases (if those are sent), it always causes a connection error and kills all transactions on the connection.