Replace `rumqttc` with a crate that is reliable enough to implement the bridge in the mapper

[didier-wenzek]

The bridge, from the gateway device to the cloud, is the only explicit dependency of thin- edge on mosquitto. Furthermore, this bridge is working as expected only with a very specific version of mosquitto (namely 2.0.18).

It would be good to have the freedom to choose the MQTT broker and to have a less strong dependency on a very specific version of mosquitto. So, why not let the mapper implement itself the bridge feature? Republishing any messages received on a c8y/# topic to the corresponding topic on the cloud endpoint (and vice versa).

Unfortunately, the crate currently used (i.e. rumqttc) is not robust enough to implement a bridge that is reliable. This has to be confirmed, but this crate provides no way to control acknowledgements for messages with QoS 1 and 2.

One needs an MQTT crate that supports:

• MQTT 3.1
  • at least the features used by mqtt_channel
• TLS
  • with certificate-based authentication of the broker and the client.
• Reliable support of QoS 1 and 2.
  • either to be able to acknowledge the reception of a message from one peer only when its copy has been acknowledged by the other peer
  • or to be able to acknowledge the reception of a message only when persisted on disk and ready to be republished till the other peer acknowledges it.
• cross-compilation to various architecture
  • ideally as a static lib and using cargo zigbuild.

[jarhodes314]

So the situation with the crates appears to be as follows:

Rumqttc

Pros:

• Easy to enable manual acknowledgements
• Implemented in Rust and an existing dependency, so there won't be unexpected issues with (cross) compilation Cons:
• Difficult (although I don't think impossible) to establish when a published message has been acked
• No built-in support for persistence, this would have to be dealt with manually

Paho

Pros:

• Based on a widely used C library, so more "battle tested" than rumqttc
• Simple interface to handle persistence without the need to do so manually Cons:
• OpenSSL has proven tricky. I have so far had no luck in both (1) getting the mapper to cross compile when using paho-mqtt (which only worked with the vendored-ssl feature) and (2) getting the connection to actually work when in a working configuration for cross compilation (when using the vendored-ssl feature, the working code mysteriously failed with an error message of TCP/TLS connect failure). This likely also means that we will encounter issue building/running containers, I've seen similar problems in "thick" edge.
• No obvious interface for manual acknowledgements
• More error-prone interface than rumqttc, no warnings if you don't await critical things.

As a result, I am trying to persue a rumqttc-based approach due to the complexity involved in paho and openssl.

[gligorisaev]

QA has thoroughly checked the feature and here are the results:

• [x] Test for ticket exists in the test suite.
• tests/RobotFramework/tests/cumulocity/telemetry/thin-edge_device_telemetry_built-in_bridge.robot
• tests/RobotFramework/tests/cumulocity/shell/shell_operation_built-in_bridge.robot
• [x] QA has tested the function and it's functioning according