http-client: fix WS client closing

[nick1udwig]

Problem

1. I can receive WS messages other than Close after closing a WS client,
2. The task is never cleaned up.

Solution

1. Remove item from map immediately upon a close & use that as sign to not send,
2. Clean up the task with should_exit flag.

Docs Update

None.

Notes

This is technically a breaking change because it is plausible that a user might have relied on some messages sneaking through. If they did that would be highly unreliable. Good thing this release is a breaking release anyways!

TODO: test using https://github.com/nick1udwig/comfyui_provider which unearthed this issue to begin with

[dr-frmr]

LGTM!

[nick1udwig]

Realizing a pretty unintuitive behavior that results from this + our send_and_await semantics.

My expectation was that when I close WS, I should receive an Ack and then the only subsequent WS message I should ever receive should be a Close. Instead, I am observing the receipt of some number of WS content-ful messages in addition to the Close after closing.

What is going on here is:

1. WS is receiving frequent messages,
2. Close the WS & await the Ack,
3. Before Ack arrives, multiple WS content-ful messages have arrived and been sent and are now in my process message queue,
4. WS is closed, Ack arrives, process unblocks,
5. Work through queue, including the WS content-ful messages,
6. No more additional WS content-ful messages are added to queue, but eventually the Close comes in.

This is pretty unintuitive. I don't know that it breaks anything, but it does add some annoying boilerplate I have to add to properly handle the WS useless content-ful messages post close.

[nick1udwig]

I guess its not terrible since you have to handle the Close anyways.