Async clipboard API: improve task source usage.

This effectively gets rid of the "in parallel" part of the
spec algorithms that say "create a promise, then in parallel".
This parallelism isn't necessary and introduces races.
See w3c/clipboard-apis#202

Example of a fixed race: the check that the renderer is focused.
This check could have failed if the site lost focus very shortly
after using the clipboard (albeit not a very catastrophic outcome).
It also has the effect of eliminating an extra copy of clipboard
data, which could save a lot of memory depending on the size of the
payload.

This change also introduces a task source for the clipboard
as mentioned in
https://www.w3.org/TR/clipboard-apis/#clipboard-task-source

This task source is useful for making sure multiple clipboard
operations (reading, writing to the system clipboard) are not
occurring in parallel. Other steps, like when an error condition
causes a promise to be rejected, need not be executed on that same
task source. Note that the spec currently fails to describe many
of the error conditions that Chromium implements. Also note that
Chromium's implementation fails to group steps that should
be part of a single operation into a single task in the queue.
See crbug.com/1510722

Bug: 1510722,1501971
Change-Id: I2eb7e8ca61bd3f7f1830514c8a68b3f1ddec042a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5113849
Reviewed-by: Anupam Snigdha <[email protected]>
Reviewed-by: Daniel Cheng <[email protected]>
Commit-Queue: Evan Stade <[email protected]>
Reviewed-by: Scott Haseley <[email protected]>
Cr-Commit-Position: refs/heads/main@{#1236575}


CrOS-Libchrome-Original-Commit: 35ff80a930b42b4aa25bf8b0e8624448c9c34f35

base/tracing/protos/chrome_track_event.proto

@@ -751,6 +751,7 @@ message RendererMainThreadTaskExecution {
     TASK_TYPE_STORAGE = 82;
     TASK_TYPE_NETWORKING_UNFREEZABLE_IMAGE_LOADING = 83;
     TASK_TYPE_MAIN_THREAD_TASK_QUEUE_V8_LOW_PRIORITY = 84;
+    TASK_TYPE_CLIPBOARD = 85;
   }
 
   enum FrameType {