fix: refactor fast timers, fix UND_ERR_CONNECT_TIMEOUT on event loop blocking

[Uzlopak]

superseeds #3494
superseeds #3418
fixes #3493
fixes #3410

• an internal "clock" is now used instead of Date.now() - ensuring that changes of the system clock wont effect the timers
• timers.js exports a now method to retrieve the value of the internal clock
• fasttimers clearTimeout expects a FastTimer instance or a native Timer. Before it accepted also undefined or null values
• connect timeouts are now using fasttimers

Based on the work of @ronag i refactored the fast timers and hopefully fixed also the connection timeout bug when the event loop is blocked.

[ronag]

This is a huge PR... not sure I have time to review properly in forseeable future.

[thisislvca]

This is a big issue over at Vercel, know it's a big PR but it's also quite important for lots of people :)

[ronag]

There are simpler PRs that solve the issue. I think the problem here is that we are combining a significant refactoring with bug fixes.

[mcollina]

LGTM

can you run the benchmark before/after to see if this impacted us at all?

[mcollina]

After a quick skim it seems fine, and all tests are passing. If it introduces some regresisons, then I'm pretty sure some users of Next.js/Vercel would report this quickly find out.

[ronag]

I'm +-0

[Uzlopak]

I want to add a small explaination of this refactoring.

I wanted to modify the fasttimer implementation. Yes it is kind of simple while you are implementing it and everything makes sense. But when working on it the first time, it is kind of hard to grok. So I started to comment the code and e.g. also replace the magic numbers with constants, and renamed the atrtibutes to be more expressive.

While I was investigating how the native timers are structured, I realized I should use their data structure/naming of the attributes. Thats why I renamed e.g. delay with _idleTimeout or callback with _onTimeout.

Also I tried to rename variables. when a different name was making more sense. E.g. in client-h1.js value to delay.

So in my opinion to review the timers.js file the first step is to just read the comments and check if it matches with the code it describes. And if it is good commented you should have a good idea on how the fast timers actually work.

The rest should be then easy to review.

[ronag]

IMHO all the comments and explanations make it harder to grasp and read. But if everyone else is happy with it I won't block. Good job.

[ronag]

Could you maybe summarize what behavior changes this introduces?

[Uzlopak]

Of course. I will in about 30 min, when i am back from groceries shopping ;)

[Uzlopak]

Well, I was looking into the code while writing what changes I implemented. I made a coverage check and realized, that the changes in client-h1.js seem to be not covered by a unit test. So I am currently implementing a unit test for that, just as a sanity check.

[Uzlopak]

I reverted the changes regarding timeoutDeadline in client-h1,js as those changes are not covered by a unit test. As soon as I find a test case and those lines fix the test then I would add them back.

[thisislvca]

Is there a chance to push out the Vercel-related errror fix first (so the most urgent) and then open a separate PR for everything else?

[metcoder95]

lgtm