Reduce size of request id for command and control responses

[pellmann]

When with Command and Control, the adapter sends the command to the device it sends a request-id. This request-id needs to be used to send the command response back to the adapter from the device. (It is not defined how this id is structured or how long it is)

It need to transport the reply-id to build or find the AMQP response link and also the correlation-id to send with each command response to the application.

At the the moment this reply-id is very long, because it is build up of two UUIDs.

This could be reduced in our client implementation:

• The message-id, which is always scoped to the one link could be a simple counter.
• The uniqueness of the link (for this tenant/device combination) depends on the application and how much instances will communicate with the device at the same time. So this should be settable by the application. In most cases a single character like 'a' should be enough.

[sysexcontrol]

Reminding of the discussions we had about shortening MQTT topics, I find very short command request ids quite important. With protocols like Sigfox there is usually a payload uplink limit of only 12 bytes. It is not quite clear to me if we have to put the hono command request id somewhere into the payload or if it can be added by something like a Sigfox protocol adapter - but if it has to be part of the payload, it could be quite dramatic regarding really short ids.

Summary: :+1: for really short command request ids, at least for the possibility!

[pellmann]

https://github.com/eclipse/hono/commit/8d1dbe79e6baae0ab5aada77594537948c4c7ff8