Close request body async iterator when a write error occurs

[Dextheking1]

Closes encode/httpx#3597.

What

AsyncHTTP11Connection._send_request_body now closes the request body's async iterator in a finally block, so it is cleaned up on both the success and failure paths.

Why

When a WriteError is raised part-way through sending the request body, handle_async_request catches and suppresses it (to allow reading a pre-emptive error response from the server), but the request body's async iterator was left abandoned mid-iteration. It was then garbage collected without ever being exhausted, producing:

ResourceWarning: Async generator '...' was garbage collected before it had been exhausted.
Surround its use in 'async with aclosing(...):' to ensure that it gets cleaned up as soon as you're done using it.

Note: closing the iterator (rather than calling request.stream.aclose()) is what fixes this, e.g. httpx's ByteStream.aclose() is a no-op, while the abandoned object is the generator created by stream.__aiter__(). The aclose call is getattr-guarded so streams whose iterators lack aclose keep working.

Test evidence

New regression test test_http11_write_error_closes_request_body in tests/_async/test_http11.py: a network stream that raises WriteError mid-body, asserting the body iterator receives GeneratorExit while the WriteError stays suppressed and the response remains readable.

Before (on master, trio backend):

ResourceWarning: Async generator '...TrackingBody.__aiter__.<locals>.gen' was garbage collected before it had been exhausted. ...

After: no warning; tests/_async/test_http11.py, 28 passed (asyncio + trio backends). ruff check and ruff format clean.

[jacksonsr451]

Hi! I investigated the async request-body iterator cleanup related to encode/httpx#3597 and reviewed this PR.

I found one additional cancellation-safety edge case: when an async generator's finally block contains an await checkpoint, Trio cancellation can interrupt the unshielded aclose() before the generator finishes cleanup.

I reproduced this deterministically against the current PR implementation. The regression test fails under Trio without shielding and passes under both asyncio and Trio when aclose() is wrapped with HTTPCore's existing AsyncShieldCancellation.

I also ran the full HTTPCore and HTTPX test suites, comparing the complementary change against the PR head. The observed failures were reproducible on the unmodified PR implementation.

I have a minimal complementary patch and regression test prepared locally. Would you be interested in incorporating this cancellation-safety improvement into the existing PR?

Thanks!