Better handling of potentially long running operations

[klassenjs]

For potentially long running operations (for example #720), evaluate moving the calculation to a worker (moving it out of the main UI thread) and providing user feedback if it isn't finished after a few seconds. Possibly via a progress bar and/or option to cancel.

[klassenjs]

Looking at this more, I'm starting to really like the idea. It could potentially move all the JSTS/turf stuff out of the main geomoose.js library and into it's own worker. The worker would respond to messages for the various JSTS operations we support. Message could contain the operation type ('buffer', 'union', etc.) and the source GeoJSON. The worker returns the result GeoJSON. This likely involves copying the potentially large GeoJSON back and forth between the worker and main thread. There are some workarounds for this using Transferable objects (ArrayBuffer), but I don't know that using them is feasible/appropriate.

We'd need additional target libraries in the webpack config to generate the worker.js files. This isn't too hard (I've done this before). And it should significantly reduce the size of geomoose.js by not requiring JSTS linked in. This saves about 15% (300kB off geomoose.min.js, and 2MB off geomoose.js).

The real issue will likely be refactoring the JSTS calls to deal with the asynchronous nature of sending a message to a worker and waiting for a response. Unfortunately, the JSTS calls are part of the exported GeoMoose API (in index.js) so removing them or replacing them with async versions might not be allowed unless we go to a 4.0.0 release. Although we could always add async versions next to them and deprecate the existing versions, but then there is no savings in geomoose.min.js).

[klassenjs]

I think the only place jsts is used in the code right now is in src/gm3/components/map/index.js:addSelectionFeatures(). I would have thought it would have been used in more places.