sse: add support of SSE on new clever client

[pdesoyres-cc]

What this PR do?

This PR adds support for SSE:

• in the mock-api test tool
• in the base client framework
• implement all logs command

How to review

• check the commit
• try stream commands

[florian-sanders-cc]

I've tested with the examples provided in the docs and it works great 😎
It's very easy to set up and use so really great job 🙌

Didn't see any issue with the docs or the code but I just discovered the subject today so 🤷

[florian-sanders-cc]

Ah well, I just remembered: not related to this PR but we could add the cors: true to the examples now that it's false by default, WDYT @pdesoyres-cc?

[hsablonniere]

👏 Impressive work @pdesoyres-cc, well done !!

👍 I had to ask Claude some help for the review but the fact that he was able to understand your code really well was a good sign !!

I create a few comments and here are some more general notes:

• I had no autocomplete available for StreamApplicationRuntimeLogCommand and other commands, I'm not sure why
• We may investigate memory leaks with listeners and signals in the future, I'm not sure we really have a problem
  • Maybe we could remove all listeners when .close() is called
• Currently, we only retry on 5xx errors - we could we also retry on 408 (Request Timeout)
  or 429 (Too Many Requests)?
• What happens if resume() is called while in connecting state?
• The debugging is done with console.log, no way to plug a logger, maybe for later...
• Would it be acceptable to use AbortSignal.any() instead of the custom combine
  function?

[pdesoyres-cc]

I had no autocomplete available for StreamApplicationRuntimeLogCommand and other commands, I'm not sure why

I'm not sure to understand your problem. I tried, and I have the same behavior than when using client.send().

• We may investigate memory leaks with listeners and signals in the future, I'm not sure we really have a problem. Maybe we could remove all listeners when .close() is called
• Currently, we only retry on 5xx errors - we could we also retry on 408 (Request Timeout) or 429 (Too Many Requests)?
• What happens if resume() is called while in connecting state?

Note that the implementation of cc-stream.js is a rewrite of the old clever-cloud-sse.js. I decided to only rework the shape of the class, and keep the logic as is.

Clearly, there are way for improvements.

• CcStream instance is a one use purpose: you should not be able to use start() after streaming ended.
• Like you said, resume() should do nothing if stream state is not paused.
• You're right, we should remove listeners when .close is called.

The debugging is done with console.log, no way to plug a logger, maybe for later...

Yes, maybe later.

Would it be acceptable to use AbortSignal.any() instead of the custom combine function?

AbortSignal.any() is newly available. So we need to wait a little bit