Async refactor

[richarddd]

Description of changes

Refactor async runtime primitives

Checklist

• Added change to the changelog
• Created unit tests for my feature if needed

[Sytten]

@DelSkayn would be interested for your take on it, right now I want to say that the spawner is overcomplicated so I support a simpler event loop. Users also reported to me that some futures are not always making progress IG not awaited is js so this should help.

[DelSkayn]

This makes polling have O(n) complexity instead of O(1) as every spawned future needs to be polled everytime you are polling the spawner. That might cause exponential complexity in the worse case if last future is always the one that is ready next.

The scheduler is somewhat complicated so that polling is O(1) to avoid this. It is basically a specialized implementation of the futures crate FuturesUnordered.

[DelSkayn]

@Sytten do you have an example I can replicate of futures not being polled?

I am not sure how this PR would improve this issue. The old schedular should basically behave the same as this one, with the exception that the old scheduler didn't have to poll all the futures that are spawned, but only those that are actually awoken.

[Sytten]

@richarddavison I will create a smaller reproduction but basically we have:

import type { SDK } from "caido:plugin";

export function init(sdk: SDK) {
  sdk.events.onInterceptResponse(() => {
    console.log("1. Handler started");

    Promise.resolve().then(() => {
      console.log("2. This never executes");
    });

    console.log("3. Handler finished");
  });
}

I call the function from rust and I poll the runtime in a spawned task with the drive function. Its very weird.

Might be a quickjs issue though