feat: websocket server poc

[moreirathomas]

Description

This PR upgrade the basic http server into a websocket server, allowing continuous and bi-directional communication with desktop.

The procedure flow is:

• the server opens a http connection with the client and upgrade the connection to the websocket protocol
• the server listens forever the incoming messages on that websocket
• upon receiving messages, the server interprets the message and invoke the related method
• on "run", the server starts the run: launches a goroutine that invokes Runner.Run(), pipes the progress as messages sends via the websocket. Then, when Runner.Run() returns, the server sends the result (or the error) to the client.
• on "cancel", it cancels the run

Implementation details

At high level:

server.Handler handles websocket stuff. It has a single exported method, Handler.ServerHTTP, making it a http.Handler usable in cmd/server/main.go. We configure the handler via server.NewHandler (note: configuration from the desktop app may be injected from here).
The handler is the only one dealing with websocket directly. Serving on the correct path, it upgrades the connection, read incoming messages and invokes service's methods accordingly.

server.service interfaces the package runner.

Changes

• package server now offers a websocket server (over a plain http one)
• package socketio interfaces reading from and writing to a websocket away from struct server.service

Notes

• support json message (input)
• support json message (output)
• custom type for messages (exhaustive list)
• accept config as client input when starting the run
• unit tests (another issue)
• cleaner error handling (another issue)

Next steps suggestion

• better error handling than current { event: 'error', error: 'reason as string' }
• generate access token on the user machine and provide it to the server on start up
• server.Handler restrict concurrent connections to /run to 1

Closes #12

[moreirathomas]

We receive a config as JSON, but nested inside a message object. To decode the message we use websocket.Conn.ReadJSON(), which limits us given its signature: we have to give it the struct we want to decode the message into.

We already faced issues with JSON configs when parsing a config file, thus the package configparse internally uses unmarshaledConfig to decode in an intermediate struct.

Given the restriction of websocket.Conn.ReadJSON(), I needed to make the intermediate struct public to exploit it.

Just to remarshal it to parse it with configparse existing api.

I suspect we need to update configparse api to handle the new use case.

Maybe out of scope of this feature.

[GregoryAlbouy]

Great!
Smooth integration with almost 0 change to the existing, also nice interfacing for socketio 👌

I left some remarks and suggestions, some of them can be addressed later (the sooner we merge this PR, the better!)

[GregoryAlbouy]

I'd be in favor of introducing actual authentication logics when they're specced rather than faking it now 🤔

Suggested change

token = "6db67fafc4f5bf965a5a" //nolint:gosec

[moreirathomas]

Thing is we need to have a mean to go around the cors.

So the token is needed in this pr.

Are you in favor of not even passing it as a argument from main (where it will be passed from anyway) and in-line it in server?

[GregoryAlbouy]

We can still return true in CheckOrigin for now and implement the token logics later (I don't see how it is different from using a token that obtainable from the repo)

Regarding its implementation I'd keep the current one, except we get token from an environment variable instead of a hardcoded public value.