Implement websockets

[FelixMalfait]

This is the first step towards a really cool feature: real-time sync.
The goal is to have a real-time multi-players experience soon.
Building a first version shouldn't be too complex as the project is already built upon strong foundations (Apollo on frontend, events already implemented on the backend, etc.)

We will break down this work into multiple issues to review PRs step by step

Here are the steps for this first issue to do a proof of concept.
Steps:

• Create a feature flag IS_REAL_TIME_SYNC_ENABLED
• Create new module for subscriptions ; I think it will be too hard to implement subscriptions within the /graphql endpoint which has a lot of custom logic so we might as well create a new /sync endpoint with a separate yoga server, call it /ws ; https://the-guild.dev/graphql/yoga-server/docs/features/subscriptions#graphql-over-websocket-protocol-via-graphql-ws
• Create a listener to dispatch the existing object events sent by the query runner service (e.g. company.updated, company.deleted...) to the subscription
• Follow instructions here to prepare the websocket connection on the frontend: https://www.apollographql.com/docs/react/data/subscriptions/
• Console.log the received events in DB

Note: I was initially in favor of implementing SSE instead of WS but changed my mind again.
Because we might have a use-case for bi-directionnal communication as some point (possible it seems), for exemple moving the track() analytics endpoint called by frontend on every pageview (in the future we'll be displaying who's viewing the same page "live" and their status, like on Google Docs)

[i-am-chitti]

@FelixMalfait SSE are great for unidirectional communication. But making it bidirectional has its own benefit. As this application is gonna be enterprise grade tackling numerous use-cases, I think decision to go with WS is gonna be scalable.

The issue looks cool and complex at same time. I would love to work on this from the very start. Wish me good luck, I'm starting on this. Will be reaching out to you in case of queries.

[FelixMalfait]

@i-am-chitti great! fyi I changed the structure of the Events object a bit and renamed it to AuditLog in this PR which hasn't been merged yet: #4936

I also think it's a cool and interesting issue, never implemented WS myself and curious to see how it plays out!
Next step after console.log will be to inject the events we receive to update the apollo cache

[FelixMalfait]

Feel free to DM me on Discord if you need help @i-am-chitti

[i-am-chitti]

@FelixMalfait, What do you mean by this?

Console.log the received events in DB

Like on getting event streams from Websockets on frontend, I should only do a console.log, right? Then, what's the DB referred to here?

[FelixMalfait]

@i-am-chitti I meant that as a first step we could just console.log the events received from the backend and not to the work of injecting them in the apollo cache (that can be in another issue/pr)

The events that are sent to the frontend are also logged in the database (in the "AuditLog" table in my new PR, in Events table currently)