Support informational responses in HTTPClient

[ehaydenr]

Informational responses are not made available to the caller. https://datatracker.ietf.org/doc/html/rfc9110#section-15.2-4 mandates that proxies forward informational responses. That's not possible if the client API doesn't make them available.

[FranzBusch]

From a design perspective I think we should introduce a HTTPClientResponseHandler protocol similar to the HTTPServerRequestHandlerProtocol. This protocol can look something like this:

public protocol HTTPClientResponseHandler<ResponseReader>: Sendable {
    associatedtype ResponseReader: ConcludingAsyncReader, ~Copyable
    where RequestReader.Underlying.ReadElement == UInt8, RequestReader.FinalElement == HTTPFields?

    func handleInformationalResponse(response: HTTPResponse) async throws
    func handleResponse(
        response: HTTPResponse,
        responseBodyAndTrailers: consuming sending ResponseReader,
    ) async throws
}

We can then make all of our currently closure taking APIs conveniences on a HTTPClientClosureResponseHandler similar to how the server API does it.

[guoye-zhang]

What about a callback on the RequestOptions? Some clients might not be able to expose informational responses

[ehaydenr]

With Franz's suggestion, if a client doesn't expose informational responses, couldn't they just not call handleInformationalResponse?

[guoye-zhang]

This ties to #141. How do libraries know if this feature is supported by a client passed in? We had a lot of discussions about that