recv_go_away closes all streams with id > last_stream_id, regardless
of which endpoint initiated them. When a client sends GOAWAY(0) to a
server, client-initiated streams (e.g. stream 1) are incorrectly
closed, killing in-progress response bodies before any DATA frames
are sent.

Add peer.is_local_init(stream.id) check so only locally-initiated
streams above last_stream_id are closed, per RFC 9113 Section 6.8.

Added test client_goaway_does_not_kill_remote_initiated_streams that
verifies the server completes a streaming response body on stream 1
after receiving client GOAWAY(NO_ERROR, last_stream_id=0). The test
fails without the fix and passes with it.

Closes #885

…884)

improve test

* add failed testcase for poll_informational

* check final response in poll_informational

…serve_capacity (#893)

See:
* Golang: https://github.com/golang/net/blob/0a81d5af911d6b2c1ad6c271c6aa2fe09747fd75/http2/server.go#L1440-L1453
* nghttp2: https://github.com/nghttp2/nghttp2/blob/1f8481251cb28848b45d950de6cad6a1311eedf5/lib/nghttp2_session.c#L6935-L6960

When h2 sends GOAWAY and then receives DATA on a stream above the GOAWAY
`last_stream_id`, the data is correctly ignored, but flow control
capacity is leaked at the connection level. This can cause an issue with
streams lower than `last_stream_id` being stalled forever.

`set_reset` notified `recv_task` and `push_task`, but not `send_task`.
This meant `poll_capacity` and `poll_reset` were never awoken for library
resets. For example when a WINDOW_UPDATE overflows.