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/netLog.ts 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]

Does an errored socket need to be closed? I think an error will automatically destroy the socket.

[EhabY]

The answer here quotes the RFC6455, but in essence it is likely that it will be closed but we cannot be sure about this :/

[code-asher]

Yeah the close event may not fire, but the underlying connection should be closed if it is still open, so calling close should be a no-op.

the client MUST Close the WebSocket Connection

Not that this really matters! It just felt like something we could leave to the library to handle, to me.

[EhabY]

Ah I see your point, the Mozilla documentation:

The error event is fired when a connection with a WebSocket has been closed due to an error (some data couldn't be sent for example).

I honestly I'm not sure if the ws implementation follows the same standard here or is there a chance an error is triggered while keeping the socket open. I quickly looked at the implementation there and it seems to always call close after an error so I'll remove this for now

[EhabY]

Yet in coder/coder there is a piece of code that does this:

socket.addEventListener("error", () => {
	onError(new Error("Connection for logs failed."));
	socket.close();
});

I am confused 😭

[code-asher]

Ah yeah I think this is a common mistake.

is there a chance an error is triggered while keeping the socket open.

I think, if the library did decide to keep the connection open (assuming it even can), that implies the connection is still usable, so we should keep using it. Or in other words, we can defer to the library's judgement, hopefully.

[code-asher]

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