Features:
- Written according to the specification of MQTT5 (from 2019).
- Supports multiple clients, i.e. connections to multiple brokers at the same time (requires more testing).
- Supports QoS0, QoS1 and QoS2.
- The UserProperty field (see spec), from all packet types, is enabled by a compiler directive, to save some space.
- Single event (for callback) of multiple error codes.
- Compiled and tested both for Desktop (FreePascal) and on MCU (PIC32).
- Because MQTT works with multiple pieces of data, of many sizes, the DynArrays library (which is a dependency) allows "rounded" allocation, which reduces memory fragmentation.
  Stability tests proved this feature to be a requirement, no matter how many fragments the memory manager supports.

What is not tested or implemented:
- The use of Topic Aliases.
- Responding with Disconnect to various error conditions (e.g. duplicated messsages).
- Responding with various error codes to server (e.g. "Protocol Error", "Payload format invalid", "QoS not supported", "Topic Alias invalid"  etc).
- Properly reacting to various server error messages, to free resources.
- Caching topic names for later correlation (e.g. between a subscription and a received message).
- Auth, other than plain username+password on connect.
- Retain.
- Will.
- Reconnecting.
- Clean/Reused sessions.
- The use of timeouts and expiration intervals (e.g. Message Expiry Interval).
- Compatibility with clients or servers of older protocol versions (e.g. v3.1.1).
- Handling DISCONNECT packet, which should automatically free some resources.
- Using SingleOutputBuffer. This is a feature, which automatically concatenates output packets into a single array of bytes.
- Using the library in a real life scenario, where the MCU stays connected for a long time.

Limitations:
- Heavily use of inversion of control. That requires using additional FIFOs between MQTT library and Ethernet library.
  This may complicate user code, because of many required callbacks, where MQTT parameters are configured.
  Some of the internal library functions are exposed, so that users may replace existing logic with theirs, thus bypassing callbacks.
- Havily use of dynamic memory allocation.
- No safety mechanisms (so far) for dealing with too large packets. In case of OutOfMemory errors, the memory manager will have to be reset.
- Although clients can be created and destroyed dynamically, users have to make sure their instances are not in use while destroyed.
  The same limitation applies to all clients which have a greater index in the array which holds client instances, because they will be reindexed.
- The development priority has been to have a working library over an efficient one. Some areas require many optimizations.
- Very difficult to predict the required amount of memory for a given application. Because of this, only MCUs with more RAM are suitable.

Dependencies:
- DynArrays library (which depends on MemManager) for dynamic memory allocation.

Misc:
- The provided example uses "mikroMedia for PIC32MX7" board and logs MQTT activity through UART (with FT232R).
  Because of that, it requires "mikroMedia for PIC32MX7 shield".
- This example does not show how the MCU application works when it subscribes to a topic.
- No documentation available at this time.