feat(widget): Batch tile requests within an animation frame

[manzt]

HiGlass's built-in data fetching logic is designed to optimize API calls
by consolidating requests based on time, ID, and server. Our custom
Jupyter data fetcher doesn't include these optimizations.

This PR introduces a consolidator helper, which performs a much simpler
form of batching. Since we assume a single server, this function only
batches tile requests that occur within the same animation frame and
submits them together. This helps reduce the number of comms calls, and
at a minimum dedupes requests with the same tile id.

This is the approach taken in mosaic:

"As multiple queries tend to be issued in tandem (for example upon
initialization), the Coordinator waits one animation frame, collects
incoming queries, and merges those .... Upon query completion,
the Coordinator parcels out appropriate projections to clients."

Initial testing suggests it feels quite responsive!

Before (slight lag due to repeated (shared) requests)

After

Checklist

• Clear PR title (used for generating release notes).
  • Prefer using prefixes like fix: or feat: to help organize auto-generated
    notes.
• Unit tests added or updated.
• Documentation added or updated.

[pkerpedjiev]

I can't wrap my head around what this function is supposed to do.

[manzt]

It's a polyfill for something like Promise.withResolvers.

Basically, it lets you create a "deferred" value. Normally, you'd resolve or reject a promise directly within the promise body. But this popular technique lets you bring the resolve/reject functions into the same scope as the promise. This let s you return the promise directly (for something else to "await") and then pass around the resolvers for that promise to other internal functions and methods.

This lets us have a top level API of:

const submit = consolidator((batch) => {
	for (let {data, resolve} of batch) {
		resolve(data + "!");
	}
});
let aPromise = submit("a");
let bPromise = submit("b"); 

await Promise.all([aPromise, bPromise]) // ["a!" "b!"]

See how each of the callers nicely can "await" their individual submissions without needing to know about the batching. It's because we pass down the resolve for each of those separate promises to the processBatch handler.

[manzt]

Oh, actually Promise.withResolvers is pretty widely available now according to MDN. I think I'll just use it direcly.