Put uEntity instance ID into dedicated topic segment

[sophokles73]

The uEntity type and instance IDs contained in the ue_id field of
a UMessage are now being put into separate segments of topic names and
filters to support accepting any uEntity instance ID in topic filters.

Additionally, the mappign of UAttributes::ttl has been changed to use
the standard Message Expiry Interval property of the MQTT 5 PUBLISH
packet instead of using a User Property. This allows for taking
advantage of an MQTT broker's message expiration functionality.

[sophokles73]

@jjj-vtm @ValMobBIllich would you mind taking a look?

[Benedikt-Illich]

Makes sense to me! I checked and at the very least azures eventgrids support the message_expiry feature.
The only issue I could see is that there might be a discrepancy between the mqtt message expiry timer and the higher level uprotocol TTL? It should be negligible in most cases though I imagine.

For the topics Im still not understanding the logic of what gets mapped where. Maybe Im missing some part of what the UID means.
.../3BA/... becomes .../3BA/0/f...
and
.../403BA/... becomes .../3BA/4/...
so the first two digits get mapped to the new 3rd component of the topic and the last three digits become the 2nd component? Or is there more to it?

[sophokles73]

For the topics Im still not understanding the logic of what gets mapped where. Maybe Im missing some part of what the UID means.
.../3BA/... becomes .../3BA/0/...
and
.../403BA/... becomes .../3BA/4/...
so the first two digits get mapped to the new 3rd component of the topic and the last three digits become the 2nd component? Or is there more to it?

The uEntity identifier of a UUri is a u32, the 16 LSBs represent the service type while the 16 MSB represent the service instance.

The uEntity ID 0x0000_03ba has type 0x03ba and instance 0x0000 (the default instance).
This gets serialized to a URI as up://{authority_name}/3BA/{major_version}/{resource_id} and gets encoded into an MQTT topic name as {authority}/3BA/0/{version}/{instance}.

The uEntity ID 0x0004_00ba has type 0x00ba and instance 0x0004.
This gets serialized to a URI as up://{authority_name}/400BA/{major_version}/{resource_id} and gets encoded into an MQTT topic name as {authority}/BA/4/{version}/{instance}.

With the instance ID in its dedicated topic segment, we can now filter on a specific service instance or accept all instance IDs using the MQTT topic wildcard character (+).

[Benedikt-Illich]

That makes sense now thanks! I went ahead and created a small PR to implement these changes also on the transport side here: eclipse-uprotocol/up-transport-mqtt5-rust#17
Lemme know if I understood everything correctly.

[sophokles73]

@PLeVasseur would you mind taking a look?

[PLeVasseur]

Hey @sophokles73 -- LGTM. Left a question under the Connection Handling section, as I'm not too familiar with MQTT, but I think this section was already there. More a curiosity.

[PLeVasseur]

Is this, let's say, a typical strategy? I'm not familiar with MQTT 😅

[sophokles73]

Using an exponential backoff for trying to connect is a widely adopted (generic) strategy.
The hints regarding the options are MQTT specific and mostly depend on the use case.