Merge lp://staging/~mardy/location-service/providers-dir into lp://staging/location-service/trunk

WIP

Manifest-based provider loading

Don't hardcode the list of available providers. Instead, scan some directories from the filesystem ($XDG_DATA_DIRS/location/providers) for <provider>.json files, which tell which providers are available.

The goal is to allow a simple way of configuring providers; for instance, we might have a file

  /usr/share/location/providers/google-location-service.json

with these contents:

  {
    "plugin": "gls",
    "configuration": {
      "endpoint": "https://www.googleapis.com/geolocation/v1/geolocate",
      "api-key": "xyz"
    }
  }

which will cause the location service to load a "gls" plugin and initialize it with the given configuration, suitable for the Google service. Also, a user might create a file

  ~/.local/share/location/providers/mozilla.json

with these contents:

  {
    "plugin": "gls",
    "configuration": {
      "endpoint": "https://location.services.mozilla.com/v1/geolocate",
      "api-key": "abc"
    }
  }

By doing this, the user is asking ULS to create a second instance of the "gls" plugin, this time setup to use the similar service provided by Mozilla.

The ULS remembers which manifest files have been loaded (using the basename of the manifest file as a key), and will refuse to load the same provider twice. So, continuing our example above, the user could create a file

  ~/.local/share/location/providers/google-location-service.json

which would override the system one. This can be useful when a different configuration is desired (for example, we the plugin might accept a configuration option to decide which of WIFI, CellId, or GeoIP positioning methods are allowed, and the user might want to force a specific one).

Some providers are built into the location service; in order to enable them, their plugin name must be prefixed with a "@". So, to enable the GPS provider, we should create a file

  /usr/share/location/providers/gps.json

with contents:

  {
    "plugin": "@gps"
  }

(note that the filename is irrelevant in this case: what matters is the value of the "plugin" key)
The current implementation assumes that if the plugin name does not start with a "@", the plugin must be loaded using the "remote::Provider"; so, in the "configuration" key one should store the options needed by the remote provider. So, for example:

  {
    "plugin": "espoo",
    "configuration": {
      "name": "com.ubuntu.espoo.Service.Provider",
      "path": "/com/ubuntu/espoo/Service/Provider"
    }
  }

========== OPEN QUESTIONS =========

The current WIP implementation still supports passing provider options from the command line (and actually, requires that at least one provider is specified). Command line options do override those from the manifest file. However, despite having implemented this, I think that there is no point in having this code, and I'd propose removing it and letting all the provider configuration happen in the manifest. Do you agree?

Then, about remote providers, to make landing this branch as easy as possible, I'd propose (at least for the time being) to keep the existing mechanism of loading remove providers via the remote::Provider interface; we can actually get rid of the D-Bus name and path from the "configuration" key and always assume that they are in the form:
    "com.ubuntu.<plugin>.Service.Provider"
    "/com/ubuntu/<plugin>/Service/Provider"
where "<plugin>" is the value of the "plugin" key in the manifest files.

In the long term, I'd like to get rid of D-Bus and just use a socket (maybe with a p2p D-Bus server on top of it, to minimize changes -- but we should add this to dbuscpp first), because there's no need to route all location updates through the server when all we want is actually a p2p communication. But that's for the far future.