feat: add ipc wrappers

[achou11]

Closes #259

Adds IPC wrappers to allow usage where there are separate processes for the "client" and "server" side code such as React Native (via NodeJS Mobile) and Electron. These platforms typically provide some kind of channeling API that sets communication over an IPC layer, but plain usage of these APIs usually requires a decent amount of boilerplate code that matches client IPC requests to the desired server function calls and then communicating results back to the client. Using rpc-reflector, these wrappers bypass the boilerplate and allow normal usage of the server side API to occur on the client side.

// On the server (e.g. NodeJS process)

const server = createMapeoServer(manager, serverPort)

// On the client (e.g. browser window, react native's runtime, etc)

const client = createMapeoClient(clientPort)

const projectId = await client.createProject({ name: 'mapeo' })

const project = await client.getProject(projectId)

const projectSettings =. await project.$getProjectSettings()

[achou11]

@gmaclennan requesting review as in "I need help with figuring out the bugs" 😄

[achou11]

running into what seems like race condition in the second test related to client.getProject(). think there's still more work to be done in terms of properly closing rpc things, so maybe that would fix it

[achou11]

wondering if i should avoid using TypedEmitter for this so that this can run in a browser environment as well (it's used for both server and client).

I havea local implementation that works using EventTarget based on this helpful post.

one of the main differences is the spec for the dispatchEvent() method:

The dispatchEvent() method of the EventTarget sends an Event to the object, (synchronously) invoking the affected event listeners in the appropriate order. The normal event processing rules (including the capturing and optional bubbling phase) also apply to events dispatched manually with dispatchEvent().

Most notably the part about synchronously invoking listeners. Not sure if the Node implementation adheres to this or if it still behaves similar to an event emitter, but wondering if this specific detail could cause problems in our case or not.

[achou11]

i guess the simpler option would be using https://github.com/primus/eventemitter3, which is what rpc-reflector uses.

it's cool that the EventTarget approach works for our use case though!

[achou11]

addressed via e067dc3 (using eventemitter3)

[gmaclennan]

Great work on this, this is tricky code and you've solved it really well. I realised reading through this that we need to handle the case of a project not being found, or an error when doing manager.getProject(). I have given a suggestion about how to do this. We don't need a whole SubChannel for this, we just need to pass a message somehow to the client.

[gmaclennan]

Move this out of the scope of get(), into the createMapeoClient() scope.

[achou11]

addressed via fd58298

[gmaclennan]

Not a huge deal, but maybe better to put this above the switch statement (small edge case - if a subchannel was created and never started, it would accummulate a queue of all messages to all other subchannels).

[achou11]

addressed via 612f068