Fixes #352 (closed).

The technical details around this MR are quite articulate, but the short story is that now we expose a reverse proxy on port :8009 (configurable in gargantext-settings.toml under the microservices.proxy-port setting) which will intercept requests for /notes and it will serve them by hiding the actual service being used write.frame.gargantext.org which can technically be protected via a firewall if we want to, so that we don't leak the actual microservice being used to serve the notes.

Under the hood, there is quite a bit happening, but it can be summarised with the fact I had to do a bunch of trial and errors in order to correctly handle the websocket connection that CodiMD establish with the frontend, as it relies on slicing the window.url of the iframe and taking the first url fragment out of it, for which I had to take remedial measures (it's explained in the commentary for ReverseProxy.hs.

How to use it

By default, if we merge this, nothing should break, or at least I have tried to engineer things to be backward compatible; this is because the actual baseUrl of the notes service is stored in the DB, in the nodes table, and it's controlled by the mkNodeWithParent_ConfigureHyperdata' function. This MR changes this base url to point to the URL of the proxy, which means it will only apply to new nodes unless we write a trivial migration in the DB.

To say it even differently, only when we start creating new notes we will create notes that will hit the reverse proxy.

What's the advantage of this approach?

This approach has the following benefits:

• No external NGINX configuration required, it's all Haskell;

• Now we control traffic from the frontend to write.frame.gargantext.org, and we can intercept requests and potentially do different things before them hitting write.frame.gargantext.org. For example, for new Notes, the /publish endpoint will be served at something like /notes/<frameid>/publish, which means our proxy can intercept this request and maybe in the future turn that into a "ShareURL" node, without leaking the actual frameId;

• We can easily retrofit authentication, as this is just another servant api/server -- I have left this out of this MR because it's already very beefy, but all the facilities are there;

• We can reuse the existing middleware for the existing server; I have tried my best to make sure that CORS should work correctly when we use something which is not localhost;

• This design is scalable; if we want to proxy another microservice we can just pick a URL path (example: /calc) and add the relevant routes to the ReverseProxyAPI;

• It allows us to decouple "public" (for example links to the docs) vs "private" links. Eventually we can tighten the security of write.frame.gargantext.org (to not be exposed to the internet) but we can create another DNS to say public.write.frame.gargantext.org which won't be served by the proxy, and that be used to host "public" pages.

I think this should check all the requirements we had.

@anoe If you can, take 10 minutes to make coffee and read the description of this MR, as it includes important details on the design and the future direction of travel. Let me know what you think, and if you want to improve this further or change direction :)

If you have questions, please fire away.