Offline serviceworker

[steff-o]

Closes #1902

This PR contains implementation for registering a Service Worker using configuration. The main purpose is to make it possible to start an Origo application without network connection. But the service worker can be used for other purposes as well, like intercepting all network calls and add headers or handle error responses.

This PR only concerns making static assets, including the application itself, available offline. In order to create a meaningful offline application you would need more offline layers, either cached geojsons or WMSOFFLINE/WFSOFFLINE layers as implemented in #2176

This PR contains a boilerplate service worker that implements a simple cache-first strategy for offline access to static assets.

The boilerplate service worker can be activated using to following code snippet:

<script type="text/javascript">
  var origo = Origo('index.json', { 
      serviceWorker: { 
        url: "service-worker.js"
    }
  });
</script>

It caches all static assets used by the demo application, including origo cities and origo-mask layers, but no background map, so it's pretty useless.

Something about implementation decisions

Not providing a generic service worker

A service worker can be used for many different purposes and applications may have different needs, so it is not easy to write a generic service worker that works for everybody. The files needed to be available offline may differ, as well as the desired cache strategy. It is possible to write a service worker that takes the files to cache as query parameters or using a file as config with filepaths, but that would most likely require using a network first cache strategy for at least some files as the configuration itself will be cached. If using some form of authentication, the complexity will increase further with more special cases to handle.

Also the service worker must be provided as a standalone file, it can not be bundled with origo.

Configuration

It would have been possible to have the configuration in index.json. For a simple SPA without parameterized service worker it would work, but if there is server side involved and the service worker can take arguments as query parameters ( for instance a file list/url to file list or a version number) at least one file have to be fetched with network first caching strategy for the browser to detect a new cache version. By exposing the configuration in index.html it is natural to make only navigation requests network first and use a query parameter in the config url to trigger a new install.

Not using a Control

The functionality in this PR could have been a (gui less) Control or a part of the Offline control from #2176, but as controls are configured using index.json that idea was scrapped. Also putting it in the offline control would make it dependent on that control, but a service worker does not necessarily provide offline caching, so it should be possible to use without the offline control.