Implement fallback for getting UAttributes from payload if MQTT5 is not supported

[ValMobBIllich]

This fix enables using MQTT3.1 messages and still building a full UMessage from the MQTT message. This is particularly important for enabling UProtocol on systems that run threadX beacuse there is currently no MQTT5 capable client that runs on it.

[stevenhartley]

If I understand correctly, if we have MQTT3.1, the entire uMessage is in the payload including the attributes correct? This looks fine to me but you need to push an update to the spec as well to match this change.

[stevenhartley]

@ValMobBIllich I created eclipse-uprotocol/up-spec#251, can you comment on it so I can assign the ticket to you?
Thanks.

[ValMobBIllich]

If I understand correctly, if we have MQTT3.1, the entire uMessage is in the payload including the attributes correct? This looks fine to me but you need to push an update to the spec as well to match this change.

Yes! The sender would be required to serialize the UMessage according to the proto definition, then put the serialized byte array into the payload of their mqtt message and send it.

Enforcing MQTT5 compliance would be more elegant but at least on the threadX chips it would require an mqtt client that supports the full MQTT5 spec which currently doesnt seem to exist.

[PLeVasseur]

Hey @ValMobBIllich -- would you like to consider using CloudEvents as suggested here?