Add logging on all RESTful and WebSocket requests in VS Code

[EhabY]

Fixes #532

This PR introduces several enhancements to improve logging and consistency:

1. Axios Logging Interceptor
   Added a logging interceptor to the Axios instance during its creation. Each request is tagged with a unique UUID, allowing us to correlate it with its corresponding response and measure the total in-flight time. To avoid excessive noise, response bodies are deliberately excluded from the logs as they were too verbose and difficult to read.

2. Unified WebSocket Creation
   Consolidated WebSocket creation logic by standardizing on a OneWayWebSocket. For VS Code, this uses the ws Node library. Previously, there were two separate places creating their own WebSocket connections and another two relying on SSE. These SSE implementations were converted to one-way WebSockets for improved consistency and performance. Additional logging was also added to track WebSocket creation, errors, and closure events.

For now, the logging level is set to trace for non-error logs and error for errors. This can easily be adjusted later. I have also isolated the logging logic in logging so it's all in one place. Let me know if we want to add more details or possibly remove some.

[code-asher]

I have not had a chance to run it yet (hopefully tomorrow) but gave it a first pass and it is looking fantastic!

[code-asher]

Feel free to re-request a review whenever you are ready for a new one!

[EhabY]

Feel free to re-request a review whenever you are ready for a new one!

Ready for re-review 🙏

[code-asher]

Tried it out and it looks glorious

[code-asher]

One other minor note: The comment for WorkspaceMonitor mentions SSE still.

[code-asher]

I have to admit the (?b) does look kinda confusing, what do you think? Maybe ??? B to match for example 533 B would be better? Or...(>= 0 B), idk. Maybe we should try calculating the size by looking at the body?

[EhabY]

I have to admit the (?b) does look kinda confusing, what do you think? Maybe ??? B to match for example 533 B would be better? Or...(>= 0 B), idk. Maybe we should try estimating the size by looking at the body?

With estimation it looks like this (I simply use JSON.stringify(body)):

2025-09-16 12:03:27.474 [trace] → 79d177f5 GET /api/v2/workspaces?q=owner%3Ame (??? B)
2025-09-16 12:03:28.308 [trace] ← 79d177f5 200 GET /api/v2/workspaces?q=owner%3Ame (~5.48 kB) 834ms

Or possibly default to 0:

2025-09-16 12:09:31.970 [trace] → 238d9059 GET /api/v2/workspaces?q=owner%3Ame (0 B)
2025-09-16 12:09:32.862 [trace] ← 238d9059 200 GET /api/v2/workspaces?q=owner%3Ame (~5.48 kB) 892ms

But I just realized that showing this info for GET requests is a bit useless since those do not have a body anyway (always 0).

[code-asher]

I like it with the estimation!

But I just realized that showing this info for GET requests is a bit useless since those do not have a body anyway (always 0).

Ohhhhh yeah good point. Personally I like the consistency of always seeing bytes, but I will defer to you if you want to remove it for get requests or show zero. 👌

[EhabY]

I like it with the estimation!

But I just realized that showing this info for GET requests is a bit useless since those do not have a body anyway (always 0).

Ohhhhh yeah good point. Personally I like the consistency of always seeing bytes, but I will defer to you if you want to remove it for get requests or show zero. 👌

For consistency I'll show 0 for now, I was just worried it'll cause confusion since people might assume that a 0 byte is an error