This PR allows processing the stream of chunks.

<?php
$client = new class() implements HttpClientInterface {
    use AsyncDecoratorTrait;

    public function request(string $method, string $url, array $options): ResponseInterface
    {
        return new AsyncResponse($this->client, $method, $url, $options, static function (ChunkInterface $chunk, AsyncContext $context) {

            // do what you want with chunks, e.g. split them
            // in smaller chunks, group them, skip some, etc.

            yield $chunk;
        });
    }
};

Some ideas:

• custom retry/redirect logic
• align chunk boundaries with server-sent events and yield augmented chunks that know about messages (see [HttpClient] add EventSourceHttpClient to consume Server-Sent Events #36692)
• play some OAuth dance before issuing the real request
• do some live transclusion
• be creative :)

Any custom logic should fit into the $passthru filter iterator (the last constructor argument of AsyncResponse). There, one has access to an AsyncContext DTO, which allows controlling the stream, eg. to replace the current request/response, to change the passthru filter itself, etc.

The surrounding logic will catch badly behaving filters to ease spotting some mistakes (eg. never forwarding an "isLast()" chunk, or yielding extra chunks after an "isLast()" one, etc.)

For the record:

• When the chunk passthru issues many internal requests in order to complete the external one, the info of each internal request is accessible via the previous_info entry. I considered merging all internal response_headers info under the main one since that's possible, but I'm not sure it's worth the added complexity. Please tell me if you think we should do it.
• A future iteration/PR might add support for time-based events. Right now, implementing a pause in the stream involves calling usleep(), but this doesn't play really well with async. Implementing small pauses and summing them up to the target pause might be good enough - we'll need to give it a try to know better.