Support MQTT3.1

[stevenhartley]

For MQTT 3.1, the UMessage is not split up putting the attributes in the MQTT header and the payload in the MQTT payload but the entire UMessage is stuffed inside of the MQTT3.1 payload. This PR is to update the MQTT transport spec to support 3.1

[ValMobBIllich]

At first glance yeah I think its fine to say that with this change we simply support MQTT3.1. Ill think about this a little bit more though. We made a kind of similar change in a previous PR where we allow messages to not have subscription identifiers (even though those are required per the mqtt5 spec) because the azure brokers dont support them (even though they claim to be mqtt5 compliant...).

The standards seem to be a bit murky and the requirements optional in the MQTT world...

[sophokles73]

IMHO we could/should use the CloudEvent Protobuf Format for this purpose as defined in CloudEvents and updated in #248 ...

[PLeVasseur]

@ValMobBIllich -- did you have feedback on @sophokles73's proposal?

[sophokles73]

BTW up-rust already contains functionality for mapping UMessages <-> CloudEvents using Protobuf Format.