* See https://rust-lang.github.io/rust-clippy/master/index.html#/large_enum_variant

Co-authored-by: Knut Alejandro Anderssen González <kanderssen@suse.de>

## Problem

Until now, the communication between our network model and its D-Bus
interface worked only in one direction (from D-Bus to the model). And
that was pretty limiting.

## Solution

In #885 we introduce the usage of `oneshot::channel()` to enable
bi-directional communication between the model and the D-Bus interface.
It worked rather well, so it is time to extend this approach.

Some use cases that are covered:

* Perform a complex validation in the model (considering the whole
model) and return the result to the D-Bus interface.
* Return the D-Bus path of a new connection (implemented in this PR).

But there is another interesting implication: the model is the single
source of truth (no more cloned data in the interface). In the future,
we are expected to listen to NetworkManager and update some parts of our
model accordingly. Not having to replicate that information to D-Bus
(except when new things add or disappear) makes things easier.

Note: `org.opensuse.Agama1.Network.Device` and
`org.opensuse.Agama1.Network.Devices` are excluded by now.

## Testing

- *Added a new unit test*
- *Tested manually*


## To do

- [x] Reduce the boilerplate associated to the usage of channels.

Agama-weblate commit: 2ad365d9d13ef872b40b5aa4fb5bd4e99f104def

Updating the service translation files from the agama-weblate repository

- Fix several issues detected by Clippy.
- Rename agama-dbus-server "locale" to "l10n" (to avoid
`locale/locale`).
- Define some 'types' for D-Bus proxies to make easier to read the code.
- Run Clippy in the continuous integration.

Agama-weblate commit: d0322d40d617c6790d5a2767fd47ca98ff25f3e0

Updating the service translation files from the agama-weblate repository

* It prevents a "future cannot be sent between threads safely" error.

* Drop the ObjectsRegistry mutex and use message passing.
* Use `async_trait` in the network Adapter trait, although it should not
be needed in version 1.75 (another PR would follow).
* Set the minimal version to 1.74.
* Improve ServiceError messages.

Updating the tree must be done in a separate task. Otherwise, it could
fight with an incoming request for the ObjectServer mutex, blocking the
actions dispatching.

## Problem

If the network service receives an `Apply` at the same time as any other
request, it may get blocked.

## Solution

Updating the tree must be done in a separate task. Otherwise, it could
fight with an incoming request for the ObjectServer mutex, blocking the
actions dispatching.

## Using tokio-console

I decided to use
[tokio-console](https://docs.rs/tokio-console/latest/tokio_console/) to
make it easier to find the problem. This tool collects and displays
information about the asynchronous tasks in your program. In the
screenshot below you can see that the D-Bus `Set` dispatchers are
blocked.

![Captura desde 2023-12-29
10-52-45](https://github.com/openSUSE/agama/assets/15836/648e5f1e-eb6b-431b-be40-45cdeaf9e980)

Once you find the problem, it is kind of "obvious", but it may take some
time until you figure out what is happening.

To use `tokio-console` you need to add some instrumentation to your
program and, at this point, it implies adding some unstable Tokio APIs.
So if you want to give it a try, you can try the code in the
[tokio-console
branch](https://github.com/openSUSE/agama/compare/tokio-console).