feat: throttle ProgressBar updates to reduce WebSocket flooding

[silveroxides]

Implements smart throttling to reduce WebSocket message flooding while

preserving important updates like preview images.

Priority levels:

• CRITICAL: No throttling (used automatically for preview images)
• HIGH: Light throttling for core ComfyUI (100ms / 0.5%)
• LOW: Aggressive throttling for custom nodes (200ms / 2%)

The priority is auto-detected from the caller's location in the codebase.

Fixes: Frontend congestion from high-frequency progress bar updates

Result from test scenario with a node that is in LOW priority level after fix

At commit 532e285

start 14s933ms
end 36s450ms
36.45-14.933=21.517

Total time taken 21s517ms

After changes:

start 15s233ms
end 24s600ms
24.6-15.233=9.367

Total time taken 9s367ms

Before_pbar_fix.mp4

After_pbar_fix.mp4

[rattus128]

what was the motivation for differntiating between core and custom nodes? There shouldnt't be too much difference. How does it look at feel if everything just follows LOW or something inbetween like 1% to avoid the stack introspection stuff?

[silveroxides]

what was the motivation for differntiating between core and custom nodes? There shouldnt't be too much difference. How does it look at feel if everything just follows LOW or something inbetween like 1% to avoid the stack introspection stuff?

I guess my thought behind that is to ensure that live preview should always be allowed though and not throttled since if all gets throttled the same amount, then we might start dropping live preview updates to frontend which is why they are on crititcal. The rest was primarily me thinking that ensuring core component updates having less risk of being dropped. It could probably be set up to be configurable dynamically as well instead of then high/low priority.

[rattus128]

The live preview being absolute makes sense to me. I think the code location stuff splitting between LOW/HIGH is not worth it unless you have some hard data on a particular use case? Just giving everyone what you call high is a clear improvement.

The core source code layout is something that evolves so this extra sources list can easily go stale.

[Kosinkadink]

I think the most common source of the websocket flooding is just the progress updates - @silveroxides could you simplify this PR to throttle only the pbar updates? Other things can then be iterated on that in the future, but this will at least keep peeps from accidentally creating code that freezes ComfyUI 99% of the time.

[silveroxides]

@Kosinkadink It has been simplified now.

[rattus128]

LGTM