fix: Fix Mapeo window randomly not opening at startup

[gmaclennan]

There was a race condition in the app startup that sometimes caused the main window to never open. This happened if the ready event was sent to the renderer process before the renderer had attached a listener.

When debugging this error I found the whole startup sequence to be hard to debug and prone to errors, due to different processes requiring a specific sequence of messages to be passed between them. The code flow was also hard to follow, with the startup sequence relying on a mixture of promises and callbacks.

Previous architecture

This isn't comprehensive, but this is my rough understanding of how startup was working before this PR:

• Two background processes were started for (1) Mapeo Core & Mapeo Server; (2) Static map renderer (Map Printer)
• The Mapeo Core background process was run using child_process.fork(), except when running in development, when it was run using a hidden electron BrowserWindow. Map Printer ran in a BrowserWindow because it requires access to the DOM.
• Communication used electron-rabbit which in turn used node-ipc which under-the-covers used a domain socket for sending messages between processes
• The startup sequence was approximately:
  • Background processes were started
  • The main process sent an IPC message to the background processes to start listening on specified ports
  • Once they were listening, a gobal was set with the hostnames of the servers running on the processes
  • The render process was informed that the backend was ready, and would then read the globals and configure the api
  • The render process informed the main process that it was ready, and the main process showed the renderer window
• Because the code forked new processes, there was also a pid-manager to check for orphaned processes on startup and clean them up.
• The IPC link via electron-rabbit queued messages, and a pre-load script in the render process waited for an IPC message from the main process with details about creating the IPC channel

New architecture in this PR

• Background processes now all run as hidden electron BrowserWindows, with node integration enabled.
• Communication is via MessagePorts which is the recommended way to communicate between processes in Electron.
• A background-process manager controls startup and shutdown of background processes
• All startup tasks (preparing user directories, starting background processes, loading the main window) happen in parallel
• The HTTP ports used for different servers are established before anything else starts, and passed to each process (background and renderer) as startup arguments, so they are available from initialization.
• Each time the render process starts, it creates a MessagePort, and sends the port to the background process, via the main process. Theoretically this could support multiple windows communicating with the backend, but for now this is useful for supporting refresh of the render process window.
• We still do orphaned process cleanup via pid-cleanup.js, but it probably is not necessary because Electron is now managing all processes

This PR also begins incremental migration to Typescript. We are using Typescript via JSDoc comments, which allows us to write plain Javascript and add types incrementally via comments, and opt-in each file via // @ts-check comment at the top of each file. The backend code has never been type-checked, but some of the front-end code is written in Flow which we will eventually stop using.

Startup sequence

index.js

1. Ensure only one instance of Mapeo is running
2. Check for and terminate orphaned processes
3. Wait for electron to initialize
4. Get open ports for HTTP servers (checks nothing else is running on a port, then chooses next available)
5. Call startApp() in src/main/index.js

src/main/index.js

1. Attach event listeners for IPC & app exit and setup context menu
2. Create instances of all windows (loading, main window, closing)
3. Create instances of each background process window
4. Attach event listeners to background and main windows for IPC
5. Load and show the loading splash window
6. Run in parallel:
   • Initialize directories for presets & styles
   • Start Mapeo Core background process
   • Start Map Printer background process
   • Load and open main window, showing it once the app completes its first render
7. Hide the loading window, and load the closing window so it's ready

Beyond this PR

There is more re-architecture I would like to do, but I wanted to limit the scope of this PR. IPC between the frontend and Mapeo core currently has several layers of abstraction:

• Mapeo Core is wrapped in the Mapeo class, which adds new methods and modifies some existing methods
• Mapeo is then wrapped in MapeoManager which starts and stops the Mapeo Core server, and reloads config
• MapeoManager is then wrapped in "Handlers" -- methods that are called via IPC.
• IPC calls are wrapped in client-ipc (adapted from previous code in electron-rabbit that converts method calls and calls the Handlers.
• This is then wrapped in new-api.js which again adds new methods and slightly adapts some methods.

All these layers of abstraction add a lot of maintenance and create an unclear boundary between the frontend code and Mapeo Core. Ideally, the Mapeo Core API should have all the methods that the front-end needs, and we can simplify the IPC to mirror the API on the client side. One way to do this is rpc-reflector, but there is also something like https://github.com/mafintosh/hrpc.

Refactoring of this code, and creating a unified API interface for Mapeo Core that is used by both mobile and desktop, can happen in a later stage. Currently half of the API calls still go over HTTP, and it will be more efficient and simpler to use the same IPC (currently MessagePorts) for all calls.

QA check-list for merging

@gmaclennan can lead this QA

• Check all menu items still work (these use IPC which has changed)
• Check sync still works
• Check export
• Check that the app packaged for distribution works
• Check it works from first install (because initial extractions of presets has changed)

[gmaclennan]

As a side note: tested on my machine these changes improve startup time from about 1600ms to 1300ms. However, if the user had an offline map installed, before this PR startup would take >3000ms due to a bug trying to change permissions on the offline map, so users with offline maps will see a significant improvement in startup with this PR