feat(ui): rework progress event handling

- Canvas manages its own progress socket event listeners and progress event data.
- Remove cancellations listener jank.
- Dip into low-level redux subscription API to watch for queue status changes, clearing the last "global" progress event when the queue has nothing in progress. Could also do this in a useEffect I guess.
- Had to shuffle some things around to prevent circular imports, so there are a lot of tiny changes here.

invokeai/frontend/web/src/services/api/endpoints/queue.ts

@@ -78,15 +78,17 @@ export const queueApi = api.injectEndpoints({
           resetListQueryData(dispatch);
           /**
            * When a batch is enqueued, we need to update the queue status. While it might be templting to invalidate the
-           * `SessionQueueStatus` tag here, this can introduce a race condition:
+           * `SessionQueueStatus` tag here, this can introduce a race condition when the queue item executes quickly:
            *
-           * - Enqueue batch via this query
+           * - Enqueue via this query
            * - On success, we invalidate `SessionQueueStatus` tag - network request sent to server
-           * - Network request received, response preparing/sending
-           * - A queue item status changes and we receive a socket event w/ updated status
-           * - Update status optimistically in socket handler
-           * - Tag invalidation response received, but by now its payload has stale data
-           * - Stale data is written to the cache
+           * - The server gets the queue status request and responds, but this takes some time... in the meantime:
+           *   - The new queue item starts executing, and we receive a socket queue item status changed event
+           *   - We optimistically update the queue status in the queue item status changed socket handler
+           *   - At this point, the queue status is correct
+           * - Finally, we get the queue status from the tag invalidation request - but it's reporting the queue status
+           *   from _before_ the last queue event
+           * - The queue status is now incorrect!
            *
            * Ok, what if we just never did optimistic updates and invalidated the tag in the queue event handlers instead?
            * It's much simpler that way, but it causes a lot of network requests - 3 per queue item, as it moves from
@@ -94,7 +96,18 @@ export const queueApi = api.injectEndpoints({
            *
            * We can do a bit of extra work here, incrementing the pending and total counts in the queue status, and do
            * similar optimistic updates in the socket handler. Because this optimistic update runs immediately after the
-           * enqueue network request, it should always occur _before_ the next queue event, so no race condition.
+           * enqueue network request, it should always occur _before_ the next queue event, so no race condition:
+           *
+           * - Enqueue batch via this query
+           * - On success, optimistically update - this happens immediately on the HTTP OK - before the next queue event
+           * - At this point, the queue status is correct
+           * - A queue item status changes and we receive a socket event w/ updated status
+           * - Update status optimistically in socket handler
+           * - Queue status is still correct
+           *
+           * This problem occurs most commonly with canvas filters like Canny edge detection, which are single-node
+           * graphs that execute very quickly. Image generation graphs take long enough to not trigger this race
+           * condition - even when all nodes are cached on the server.
            */
           dispatch(
             queueApi.util.updateQueryData('getQueueStatus', undefined, (draft) => {