a limitation in the conditional responses handling was causing a batch
of concurrent requests to fall back to be handled serially. this
happened if i.e. requests need to be retried (via the `:retries` plugin)
or requests needed to be followed (via the `:follow_redirects` plugin),
among other use cases which followed a similar pattern.

This fixes it by drastically simplifying the session "wait for
responses" loop where multiple responses can be peeked during the course
of a single select tick, making sure that conditional responses can be
handleed in the same iteration before the flow goes back to the selector
loop.

the HTTP/1.1 test is quite flaky, as it sends a `connection: close`
header, and httpbin only sends the follow-up information status before
closing the socket, so there's not valid response.

fix: keep sending requests concurrently on conditional responses

See merge request !441

datadog spans weren't including the timeline from initializing the
connection (when it happens).

datadog: use request init time as span start time

See merge request !442