Add support for MQTT client

[tbeu]

Tested with MSVC and GCC on Linux.

TODO:

• Add ITI_MDDMQTT.dll to the Win libraries
• Wait for official paho-mqtt.c v1.3.0 release (especially with Add OpenSSL error handler callback function and context eclipse/paho.mqtt.c#521 merged) and update libs + headers
• The clientID should be shorter (max. 23 characters, typically) and could depend on getMACAddress instead of getInstanceName. Need to wait for Add utility function to retrieve MAC address #255 getting merged.
• Build OpenSSL with no-dso to avoid linker dependency on libdl

I did not spent time on setting up a local MQTT broker, thus the example works on some public test broker. This might be changed some day.

Close #130

[tbeu]

Hm, the 32-bit test at Travis CI should display linux-generic32 as platform, but also builds/runs the 64-bit binaries: https://travis-ci.org/modelica/Modelica_DeviceDrivers/jobs/422593836#L1186 Thus, there is something wrong in general with the 32-bit configuration for Travis CI.

[tbeu]

32-bit CMake cross compilation does not work at Travis CI, but I have no more ideas what and how to fix.

https://travis-ci.org/modelica/Modelica_DeviceDrivers/jobs/422716533#L807

[tbeu]

I believe it is same issue as http://cmake.3232098.n2.nabble.com/CMAKE-SIZEOF-VOID-P-question-td7595355.html.

Cross-compilation will only work by use of artificial environment variable. See https://github.com/eclipse/paho.mqtt.c/blob/4b355d1fd48c13f47fc663af4001ff23aa9d3e5a/test/CMakeLists.txt#L21-L26 for an example.

[tbeu]

4d33f14 fixes the cross-compilation issue with CMake at Travis CI in master.

[bernhard-thiele]

It took a bit of testing and some email exchange to get an understanding of this PR. It now works fine in Windows and Linux and will be cool new feature for the next release. I will squash it and merge it.

As discussed using email, the new library dependencies should be managed in a more transparent way so that it is not too difficult to reproduce the builds. However, this can be improved later. Particularly, building the OpenSSL libraries is a bit inconvenient and I like your idea of replacing that dependency by mbedTLS in the future (if possible).

I have experimented with adapting the cmake files, so that the library dependencies can be built as external projects. This is not complete, yet. I think I should do a more general revision of the cmake build system before. That's future work.

Below is what I understand about the library dependencies. We could document this at some place in the project, e.g., below the ../Resources/Libraries folder. Finally, I hope that we/I can adapt the cmake files, so that the libraries can be built by cmake (and thus a simple reproducible build becomes possible at some point in the future).

• paho.mqtt.c
  • Windows: paho-mqtt3cs.[lib,dll]
  • Linux: libpaho-mqtt3cs.a
  • https://github.com/eclipse/paho.mqtt.c
  • Version 1.3.0 (Paho 1.4)
• OpenSSL
  • Windows: libeay32.dll (Windows name of libcrypto.a), ssleay32.dll (Windows name of libssl.a) (Dummy libraries: crypto.dll, ssl.dll)
    • Build as described, e.g., in https://stackoverflow.com/a/40007671/8520615, but without debug and with no-asm
  • Linux: libcrypto.a (general cryptographic support), libssl.a(client and server-side implementations for SSLv3 and TLS, needs libcrypto.a)
  • https://www.openssl.org/
  • OpenSSL_1_0_2p