Add a network D-Bus service

[imobachgs]

According to our network support design document, we decided to implement our network D-Bus API. The idea is to use the same API from the web UI and the CLI.

Of course, we are not implementing a full solution for network handling but relying on existing stuff, like nmstate.

⚠️ The PR is not ready for review yet, but comments are welcome. However, please, read the full description before reviewing the code.

Implementation

This PR adds a new network module to agama-lib. It contains:

• A data model, which is basically a wrapper around nmstate::NetworkState.
• A D-Bus service.
• A new (and temporary) package to start the service. This logic should be moved to agama-dbus-server (what about agama-service?) when it is ready (see Rust locale #533).

The D-Bus API

We tried to keep the API as simple as possible. At this point, it publishes an object for each known network device, and another for the DNS settings.

Service org.opensuse.Agama.Network1:
└─/org
  └─/org/opensuse
    └─/org/opensuse/Agama
      └─/org/opensuse/Agama/Network1
        ├─/org/opensuse/Agama/Network1/Device
        │ ├─/org/opensuse/Agama/Network1/Device/enp2s0f0
        │ ├─/org/opensuse/Agama/Network1/Device/enp5s0f3u1u4
        │ └─/org/opensuse/Agama/Network1/Device/wlp3s0
        └─/org/opensuse/Agama/Network1/Dns

Depending on the type of each device, it would expose a different set of interfaces:

• org.opensuse.Agama.Network1.Device for all of them containing general information.
• org.opensuse.Agama.Network1.IPv4 for devices that may have an IP configuration.
• org.opensuse.Agama.Network1.Wireless for wireless devices (not implemented yet).

The D-Bus architecture

When it comes to the D-Bus service, we are unsure whether the approach is right. Currently, the NetworkService holds the network configuration behind a Mutex. Given that the entry point to modify the settings is the nmstate::NetworkState itself, all D-Bus interfaces have access to that object through an Arc (and use the mutex to avoid any collision).

To do

• Add support for wireless devices
• Allow setting the gateway
• Add support to write the configuration
• "Hide" nmstate API behind our structs.
• Move the errors' definition to the right place.
• Extend the test coverage
• Emit events when a property change (most probably on a separate PR)

[coveralls]

Pull Request Test Coverage Report for Build 4828497610

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 73.786%

---

Totals
Change from base Build 4807546354:	0.0%
Covered Lines:	4759
Relevant Lines:	6218

---

💛 - Coveralls

[imobachgs]

Replaced by #272.