Async Runner with Message Channel

[flashdesignory]

As discussed in our sync, here is a combination of the AsyncRunner and Message Channel pr.

Relevant code snippet (udpated):

class AsyncRAFTestInvoker extends BaseRAFTestInvoker {
    static mc = new MessageChannel();
    _scheduleCallbacks(resolve) {
        let gotTimer = false;
        let gotMessage = false;
        let gotPromise = false;

        const tryTriggerAsyncCallback = () => {
            if (!gotTimer || !gotMessage || !gotPromise)
                return;

            this._asyncCallback();
            setTimeout(async () => {
                await this._reportCallback();
                resolve();
            }, 0);
        };

        requestAnimationFrame(async () => {
            await this._syncCallback();
            gotPromise = true;
            tryTriggerAsyncCallback();
        });

        requestAnimationFrame(() => {
            setTimeout(() => {
                gotTimer = true;
                tryTriggerAsyncCallback();
            });

            AsyncRAFTestInvoker.mc.port1.addEventListener(
                "message",
                function () {
                    gotMessage = true;
                    tryTriggerAsyncCallback();
                },
                { once: true }
            );
            AsyncRAFTestInvoker.mc.port1.start();
            AsyncRAFTestInvoker.mc.port2.postMessage("speedometer");
        });
    }
}

For testing purposes I kept an explicit type of "async" in the test file, but I opted all default suites into using it.

Initial testing shows that it should also fix the react specific issue.

Other issue solved by this pr: #83

[flashdesignory]

@rniwa - I believe we addressed all the comments. Anything else missing that I can help with?

[rniwa]

Do we really need a separate lookup table? Now that timer-based measurement is gone,
why don't we just have a single lookup table with "raf" and "async" as measurement methods.

[flashdesignory]

cleaned up!

[rniwa]

This seems to have a side effect of always pushing the measurement end until when a promise resolves.
I don't think we want to do that for rAF based measurement method (since that can affect the score)
so maybe we should check the return value of this function and await conditionally?

[rniwa]

More concretely, the following code logs: 1, 2, 3:

(async function() { console.log(1); await (() => { })(); console.log(3); })(); console.log(2);

whereas the following code logs 1, 3, 2:

(async function() { console.log(1); (() => { })(); console.log(3); })(); console.log(2);

i.e. await will always delay the execution of the continuation until the end of the current micro-task. While that's highly desirable for async measurement, I don't think we want to affect rAF measurement.

[flashdesignory]

I made it a bit simpler and just passing along a type that we can check to see if we need to await or not

[flashdesignory]

cleaned up some stuff from the developer menu integration. Previously i only checked if the suite.type is "async", which always returned false, since we removed the async type from all tests.

Now I am checking both: suite.type === "async" or "params.useAsyncSteps"

[rniwa]

Great. Thank you for addressing all the review comments!