Support for `rr.spawn(serve=True)` for multiprocess web-viewing

[teh-cmc]

Users want to be able to log to the web-viewer from multiple processes, just like they do with the native viewer.

This requires an intermediate proxy, so all the data can go through a single websocket port, which the web-viewer then knows to poll. The solution today is to manually start a tcp+websocket server with rerun --serve, then just use rr.connect() in all your clients.

That manual step is annoying, and AFAICT, could be automated away by augmenting rr.spawn().

All rr.spawn() does is basically fork_exec("rerun --port={port}"). We could add an extra serve: bool parameter, and then rr.spawn(serve=True) would bottom out in fork_exec("rerun --port={port} --serve"). Assuming our usual policy of "silently re-use the existing instance in case of conflicted ports", that means every client could just call rr.spawn(serve=True) and voila, all the processes are logging to the same web-viewer.

Related:

• 7766

[teh-cmc]

And now that I'm documenting the application model (#919), I'm realizing that doing this would provide a level of consistency that would allow me to concisely state:

rr.spawn(serve=False) = rerun &
rr.spawn(serve=True)  = rerun --serve &

and that would be very nice.

[emilk]

Ideally spawn should have all the flags that the binary has