[internal] Investigate fetch timings when Socket is reused

[Skn0tt]

          I wonder what does this mean for the timings? If the socket is reused, will it get zero `connect` timings? What if sending does not start right away - should that count as `blocked` or `queued`?

Originally posted by @dgozman in #32956 (comment)

[Skn0tt]

To answer the questions, here's what I think our behaviour should be:

• If the socket is reused, the connect timing should be -1, because that timing doesn't apply to the current request
• If sending doesn't start right away, that should count as blocked. If sending does start right away, blocked should be zero.

[Skn0tt]

My hypothesis for #32956 was that we're reusing Sockets. Now that i'm looking more into this, i'm less sure about it. The default Node.js Agent does reuse Sockets, but we use our own Happy Eyeballs implementation. Judging by its code, it doesn't reuse Sockets. I'll need to investigate that more.

[Skn0tt]

I've added some debugging into our python tests, and it indeed seems like sockets are reused. Let's find out where that happens.

[Skn0tt]

Oh, HttpHappyEyeballsAgent extends http.Agent. That explains why we're getting the socket reuse behaviour.