The task attribution algorithms don't seem to account for parallel task queuing

[andreubotella]

In the patches for "queue a task" in the task attribution integration section, that algorithm calls "get current task", which accesses the event loop's task scope task. This is problematic since "queue a task" can be called in parallel (i.e. off the main thread), which can cause it to get the wrong task ID.

Imagine the following hypothetical web API:

partial interface mixin WindowOrWorkerGlobalScope {
  void runScriptLater(URL scriptURL);
}

The runScriptLater(scriptURL) method steps are:

1. Fetch a classic script given scriptURL's URL... with onComplete being the following steps, given script:
   1. If script is null, return. (This is a failed fetch, or a response with a non-script MIME type.)
   2. In parallel, run the following steps:
      1. Wait an implementation-defined amount of time.
      2. Queue a global task to run a classic script given script.

Take the following code:

scheduleWithHighPriority(() => {
  doSomething();
  runScriptLater("https://example.com/someScript.js");
});

scheduleWithLowPriority(() => {
  doSomethingThatMightTakeSomeTime();
});

Since "queue a task" will happen at some indeterminate later point after the high priority task returns, the callback task might have no priority information, or it might happen to finish waiting when the low-priority task is running, in which case it will end up having a low priority.

I'm not sure how this could be fixed, other than by explicitly passing the parent task around every time something runs in parallel.