Enable timeout ensureSynchronized everywhere (Solution #2)

[curtisman]

Monkey patch Mocha's it function to wrap test functions and capture how long the test is supposed to run until timeout and patch the resetTimeout and clearTimeout function on the test to trap the timeout tracking in mocha. It will set up a parallel timeout that will reject a promise for timeoutPromise right before the test would timeout.

Remove the 5 min timeout for ensureSynchronized (which is unless for test) and use the now default behavior of the test timeout captured above. The purpose is to provide a better error message and stack if ensureSynchronized got stuck.

Also, change the behavior for timeoutPromise:

• when duration is <=0 or Infinity. Instead of waiting for the default amount, it will now mean it won't timeout at all. This is so that we can avoid timeout when debugging.
• By default, when no duration is specified, timeoutPromise has no affect. Only if you are inside the test function that it will use the test timeout.

Fix AB#2175

This is an alternative solution to PR #12278

[curtisman]

@vladsud This PR changes the behavior for what @anthony-murphy introduced with the original timeoutPromise concept, but it will get a more reliable timeout based on the test's timeout setup. What do you think?

It is a little bit uglier, using monkey patching, but it gets the job done. Let me know if you have any other ideas.

[curtisman]

@agarwal-navin FYI, this solution would also fix AB#2182

[anthony-murphy]

this feels like a lot of complexity to just create a timer. i think i'd prefer to just make timeoutPromise smarter, and pull the timeout off the test in the default case

[anthony-murphy]

i'm hoping we could just do something like timeout = runnable.duration - runnable.timeout() - timeBuffer

[anthony-murphy]

if not. the below code in if (globalThis.getMochaModule !== undefined) could just set some var to be the start time in runnablePrototype.resetTimeout. That and the current time would take the role of runnable.duration above

[curtisman]

@anthony-murphy Capture the end time was my original solution. But that doesn't work fully:

• if the call to set the timeout is within the test itself, then we will have reset/clear/reset/clear. We need to have a way to cancel and change the rejection timeout for timeoutPromise that is already in flight.
• resetTimeout get calls after the async test function is called returns the promise, it is too late to influence the time timeoutPromise that is already called in the test invocation before resetTimeout

Also timeoutPromise also don't have access to the current runnable. While we can capture that, but we it won't have the time elapsed so far (duration is only set when the test is done)

[anthony-murphy]

Change is flight makes sense? is it something our tests do? how high of fidelity do we want here? as i think the current mechanism would break with test parallelism?

[curtisman]

I have seen multiple test doing it at the beginning of the test. I can probably search for them and move it to outside, but I'd like to avoid it breaking in case something add a test that does that.

No. mocha parallelism is achieved via different process.