Extend shared workers to access test runs and AVA's internal events

[novemberborn]

Coming out of conversation on #2608 (comment), it'd be interesting to extend shared workers so they can access test runs and AVA's internal events.

This would allow a shared worker to write reports or interact with third parties as a test run concludes, which is especially interesting in CI setups.

Shared workers are user code that runs in a worker thread and survives across test runs. Test code can communicate with shared workers to manage state. Currently shared workers are loaded on demand from a test file.

Roughly, what we'd need:

• A way to load the worker when AVA starts up. This could be declarative in the configuration, or perhaps we can use the factory style of the ava.config.* files and provide a registerSharedWorker() function that follows ava/plugin:

  ava/plugin.d.ts

  Line 76 in ae0042c

  export function registerSharedWorker<Data = unknown>(options: SharedWorker.Plugin.RegistrationOptions<'ava-4', Data>): SharedWorker.Plugin.Protocol<Data>;

• A way so that test runs don't start before these workers are ready.

• A way for the worker to subscribe to test runs. Perhaps a runs() method like we have for testWorkers():

  ava/plugin.d.ts

  Line 19 in ae0042c

  testWorkers: () => AsyncIterableIterator<TestWorker<Data>>;

• A way for the worker to run code at the end of a test run. This could be a Run#teardown() method like we have for test workers:

  ava/plugin.d.ts

  Line 44 in ae0042c

  teardown: <TeardownFn extends () => void> (fn: TeardownFn) => TeardownFn;

• A way to limit how long these teardown methods can take to execute. For starters we could take the timeout setting and use it as a deadline. If the method does not complete then AVA will exit with an error. We could use shared array buffers and Atomics.wait() to block the main process until the deadline expires. This should be more accurate than relying on timers and the async communication between the worker threads. By which I mean, if you have 5000 ms and you complete in 4999 ms it still shouldn't fail.

• A way for the worker to access AVA's internal events. This is trickier. We don't want to send the events to all workers, so there should be some sort of opt-in when negotiating the procol. Once opted in, the worker will receive all events so there are no race conditions in subscribing to them.

  ava/plugin.d.ts

  Line 7 in ae0042c

  negotiateProtocol <Data = unknown>(supported: readonly ['ava-4']): Protocol<Data>;

• I don't want to commit to a SemVer contract for these internal events. We could add a Run#nonSemVer.subscribeToInternalEvents() method like we have for messages:

  ava/plugin.d.ts

  Line 43 in ae0042c

  subscribe: () => AsyncIterableIterator<ReceivedMessage<Data>>;

Hopefully we can do some bike-shedding on these APIs, and some folks have an interest in contributing to this!