Unbounded HTTP/2 concurrent streams and Rapid Reset denial of service in HTTP.jl server

Summary

### Description

The HTTP.jl HTTP/2 server advertised an empty initial SETTINGS frame, leaving `SETTINGS_MAX_CONCURRENT_STREAMS` effectively unlimited, and the HEADERS code path allocated per-stream state, a send-window entry, and a `Threads.@spawn`ed handler with no check on the number of open streams. `RST_STREAM` was not rate-limited, so a single connection could drive unbounded stream state and handler-task creation — the "Rapid Reset" denial-of-service class (cf. CVE-2023-44487). Separately, the new-stream guard compared `hf.stream_id < max_stream_id`, which allowed a client to reuse the highest closed stream id once it had been cleaned up, including after `GOAWAY`.

### Impact

A remote peer could exhaust a multithreaded server's memory and CPU by rapidly opening and resetting streams over a single connection, or could reuse closed stream ids to confuse connection state.

### Patches

Fixed in HTTP.jl v2.4.0. A configurable per-connection concurrent-stream cap (`max_concurrent_streams`, default 100) is advertised via `SETTINGS_MAX_CONCURRENT_STREAMS` and enforced on incoming HEADERS — an over-cap stream is refused with `RST_STREAM(REFUSED_STREAM)` without allocating state or spawning a handler. Peer-initiated resets are tracked and trigger `GOAWAY(ENHANCE_YOUR_CALM)` once they exceed `max_concurrent_streams + 100`, and new client stream ids must be strictly increasing. Set `max_concurrent_streams <= 0` to restore the previous unbounded behavior.

Reported to the JuliaLang security team through Anthropic's Coordinated Vulnerability Disclosure program.