Implement Network Settings for Ubuntu Core - closes #3155

[benfrancis]

Closes #3155

This PR implements a back end for network settings which works inside a snap running on Ubuntu or Ubuntu Core. It configures network settings using NetworkManager via its DBus API.

Previously all the Platform methods were synchronous but this introduces optional asynchronous versions of those methods.

The snap will require the network-manager and system-observe snap interfaces, which must be connected in order for it to work.

I will squash these commits before merging but have kept the commit log for now.

[benfrancis]

I think I've been working on this long enough that I should probably get someone to start reviewing it! Sorry this is such a huge patch but it made sense to do it all in one go.

@tim-hellhake I would value your input on this if you have time to review, if not let me know and I will try to find someone.

Note that the build is currently failing in CI because the dbus npm package needs libdbus to build (libdbus-1-dev apt package on Debian-based distros). I'm not exactly sure where to add that in the GitHub Action. Maybe https://github.com/WebThingsIO/gateway/blob/master/.github/workflows/build.yml#L33 ? But I feel like apt packages may be installed somewhere else as well.

If you want to give this a test drive then it should work on Ubuntu Deskop if you build from source locally as normal (need to apt install libdbus-1-dev first).

---

Generating a snap package from this branch to test on Ubuntu Desktop is a bit more involved but if you want to try it:

• Install snapcraft
• Edit snapcraft.yaml to change the "source" of each "part" to "." so that it builds from the local source instead of GitHub master
• $ snapcraft
• $ snap install --dangerous webthings-gateway_2.0.0_amd64.snap
• $ snap connect webthings-gateway:system-observe
• $ snap connect webthings-gateway:network-manager
• $ snap restart webthings-gateway

The snap currently runs on port 8080 by default.

The same snap should run on Ubuntu Core on the same architecture.

[tim-hellhake]

I would delete this part completely

[benfrancis]

@tim-hellhake Thanks for the review!

I addressed your comment and managed to get it to build in CI by adding the DBus dependency to the GitHub Action via apt.

However, for some reason the integration tests appear to all pass but then the task times out after 6 hours! Any ideas what might be going on there?

[benfrancis]

It does appear to be something in this PR which is causing the tests to time out, but I'm a bit stuck figuring out what it is. The actual tests seem to pass but then jest times out and eventually gets killed.

The only idea I've had so far is that Dbus.getBus() is keeping something open that is preventing Jest from finishing. Maybe rather than opening that when the class is instantiated there should be some kind of init() method on Platform which is called when needed... but I'm really just guessing.