fix: adjust expiring reset stream limits

[seanmonstar]

h2 has mechanisms to remember a local reset stream for some time afterward, to support what it says in RFC 9113 SS 5.4.2:

A RST_STREAM is the last frame that an endpoint can send on a stream. The peer that sends the RST_STREAM frame MUST be prepared to receive any frames that were sent or enqueued for sending by the remote peer. These frames can be ignored, except where they modify connection state (such as the state maintained for field section compression (Section 4.3) or flow control).

Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame for any stream. However, an endpoint MAY send additional RST_STREAM frames if it receives frames on a closed stream after more than a round-trip time. This behavior is permitted to deal with misbehaving implementations.

We don't want to remember the streams for forever, that would cause memory to grow. Nor do we want to accept frames on those streams without limit, since that would waste resources. Thus, we limit how much we remember, by stream count and duration.

This PR changes the defaults to be something perhaps a little more reasonable:

• 50 streams, a conservative amount of half of the recommending minimum concurrent streams any remote SHOULD support.
• 1 second, since the RFC only suggests about 1 RTT. We don't keep track of RTT, but even p99 RTT is around 250ms, maybe 500ms.

One possibility is having different values for server and client, since servers are usually more interested in constraining resources, but at the same time, many servers also contain clients.

cc #856

[zanieb]

Thank you!