Implement MQTT related functions/resources

[purpleidea]

We might want to have MQTT related functionality in mgmt. Resources to "send" values and a function to "receive" values.

I'm going to keep this wide open for now, so that @lourencovales can have fun designing the "API". Let's focus on a resource first, and functions as step two.

Let's work on your design in this issue. It probably makes sense to have the following:

1. Some mcl pseudo code of how this would work.
2. Some suggestions about which libraries to use and pros/cons of each.
3. An analysis of those libraries to see how you could get an event. (We don't want polling.)
4. Some pseudo code of how it might tie in with future mqtt related functions. (Bigger mcl example.)
5. A minimal prototype of MQTT doing it's thing before you try to glue it into the mgmt code base.
6. A way to mock MQTT "client"/"server" sides to test it all for yourself when developing.
7. A discussion about how we would eventually test all this.

Any questions, let me know!

[lourencovales]

This could be an example of how we'd handle the resource for publishing events

import "mqtt"

mqtt "client-reallycool" {
    connect => "tls://127.0.0.1:2929", 
    topic => "reallycool/event",
    message => "this event is off the charts",
    flags => struct {
        ConnectRetry => 2,
        ...
    }
    ...
}

[lourencovales]

As for libraries, I've found a few candidates:

• https://github.com/eclipse-paho/paho.mqtt.golang/ (https://github.com/eclipse-paho/paho.golang is the v5 implementation) is the most widely used library for an MQTT client in go. Unfortunately seems like their license (EPL2.0) is not compatible with GPL3.0 mgmt uses
• https://github.com/mochi-mqtt/server - this is a full server implementation, but I think we may be able to just use the client part here? The license is MIT, it's still being actively developed, and supports both MQTT v3.1.1 and v5, as well as a ton of hooks and events
• https://github.com/at-wat/mqtt-go - "just" a client, supports v3.1.1, still seeing development, license is compatible

These seem to be the 3 best choices I've found, but I'm not super experienced in evaluating this.

@purpleidea what do you think for now?

[purpleidea]

TBQH I'm actually a bit surprised how big all these libs are, but it's a good exercise in learning how to tackle what looks like overwhelming API surface.

Probably we want the second two. We definitely want to avoid EPL. mochi for the server side, and if they have client parts that's fine too. As a backup for the client side we can use the at-wat or something else.

[lourencovales]

Regarding mochi, seems like getting events from it should be relatively easy. They have this concept of "hooks", and if the example provided is anything to go by, it should be rather easy to implement this on mgmt's end, both from the client and server side.