Map httpcore exceptions for Response read methods

[j178]

Fix #1188
Add map_exceptions to Response.iter_raw and Response.aiter_raw, making sure all httpcore exceptions are mapped.
And add a slow_stream response test to make sure ReadTimeout ocurred while the client is reading the response body, not in the request time.

[florimondmanca]

Interesting…!

The main reason I'm not immediately "OK let's go" on this is that ReadError & co only have a request=... parameter, but in this case we do have a response available that we could attach to the exception. Perhaps no need to sweat it since we have the response object available in the scope anyway when doing local exception handling, but just wanted to leave this heads up.

with httpx.stream(...) as response:
    try:
        for line in response.iter_lines():
            ...
    except httpx.ReadError as exc:
        print("Stream broken", response)  # No need for `exc.response` anyway?

[lovelydinosaur]

@florimondmanca Well noted. There's already other exception classes that can fall into that category, which I'm totally okay with, because it's consistent & simple. As you say, the response will be available in the local scope anyways.

[lovelydinosaur]

There's also an alternate implementation where we wrap around the stream that we pass to the Response instance, here...

httpx/httpx/_client.py

Lines 795 to 801 in d10b7cd

	response = Response(
	status_code,
	http_version=http_version.decode("ascii"),
	headers=headers,
	stream=stream, # type: ignore
	request=request,
	)

Eg. something along these lines...

ResponseStream(ContentStream):
    def __int__(self, request, stream):
        self._request = request
        self._transport_stream = stream

    def __iter__(self):
        with map_exceptions(HTTPCORE_EXC_MAP, request=self._request)
            for chunk in self._transport_stream:
                yield chunk

    def close(self):
         self._transport_stream.close()

Then...

response = Response(
   ...
   stream=ResponseStream(request, stream)
)

I don't see any reason for us to prefer that here & now, but mentioning it in case it's a useful reference point for anything in the future.