Improve spec compliance of the event-loop

[gterzian]

Spec: https://html.spec.whatwg.org/multipage/#event-loop-processing-model

which is also called into by step 29 of https://html.spec.whatwg.org/multipage/#run-a-worker

We have two implementations of the event-loop:

1. In ScriptThread, representing a "similar-origin-window-agent", running an window-event-loop at

   servo/components/script/script_thread.rs

   Line 1380 in 5372931

   while self.handle_msgs() {

2. In AbstractWorkerGlobalScope, representing a dedicated-worker-agent or a service-worker-agent running a worker-event-loop, at

   servo/components/script/dom/abstractworkerglobalscope.rs

   Line 97 in 3996326

   pub fn run_worker_event_loop<T, TimerMsg, WorkerMsg, Event>(

3. We also have paint worklet-agents running a worklet event-loop

This issue will focus on 1 and 2.

Couple of issues can be noted in both:

1. We run a microtask-checkpoint after handling any message/event, however we should only run those when mandated by the spec, such as:
   • After running a task (Step 1 of the event-loop processing model)
   • Elsewhere, for example after having update-animations-and-send-events, called into by Step 10.9
2. In the window event-loop, we have a bunch of custom logic where we first run resize events, and then prioritize some events coming from the constellation(see here), while the spec clearly says to start by running a task, if any is available, then running a microtask checkpoint, and then finally run the various optionsal steps in update the rendering, which includes for example run-the-resize-stepsat 10.6. So it appears that most of the resize and other constellation events we handle first, should be handled after the handling of a task, and in a specific order. This includes running the window animation frame callbacks(Step 10.11).
3. We don't run any animation frame callbacks for dedicated workers(which I assume only makes sense once we have transferable offscreen-canvas?).
4. I'm not sure if the generic worker event-loop was really such a good idea, because different workers might require different hooks(for example animation frames in dedicated workers), however it might also be that we can just add methods to WorkerEventLoopMethods to reflect this diversity.

[gterzian]

Re microtask, we should also run them even if there is no task to run, so instead of blocking on the select, which potentially blocks until a task is enqueued, we should do something were we immediatelly do a microtask checkpoint if not task is runnable, and then only block if there is no microtask and no task to run.

For example, if a promise resolves, and then queues another promise via a microtask, we would want it to run, even if there is no runnable task in the queue and we don't receive any other message. Currently we would block and only run the microtask when a message comes in.

See step 1: "If there is no such task queue, then jump to the microtasks step below."