Configuration-based Datasource Management

[josephbirkner]

Currently, the only way to attach datasources to mapget via configuration is by passing -d or -e arguments for connecting with remote datasources. However, it is currently not possible to configure a datasource which runs in the same process as the mapget server.

For this purpose, mapget shall support a YAML-based settings format, where datasources can be configured side-by-side with zswag HTTP credentials. A sample entry may look like this:

sources:
  - type: SmartLayerTileService
    url: https://api.nds.live/island1/openapi.json
    id: NDS.Live Island 1
http-settings:
  - scope: api.nds.live
    api-key: ...

To make this work, mapget needs to support registering derived datasource constructors for certain datasource types. To this end, a function mapget::registerDataSourceType will be introduced. E.g.

mapget::registerDataSourceType(
  "SmartLayerTileService",
  [](YAML::Node const& config) -> std::shared_ptr<LiveDataSource> {
    if (!config.has("url"))
      throw std::runtime_error("SmartLayerTileService requires a `url` config entry!");
    auto mapId = config.has("id") ? config["id"] : "";
    return LiveSource(config["url"], config["id"]);
  })

The YAML-based config file format will replace the current TOML-based one. Additionally, a mapget service running with such a config file will watch it for changes. If it changes, the service will be restarted internally. Furthermore, mapget will support GET /config and POST /config endpoints if started with --expose-config. This will allow a client (such as erdblick) to offer a GUI for editing the datasource configuration. We can reduce this privilege to a narrow subset of users by adding a check such as --expose-config-require-header OAUTH_ROLE=administrator.