Allow the client/SDK to set the message UID

[sameh-farouk]

I think it is better for the official client/SDK to handle generating UID for messages, IMO it is important for the sender to be aware of the message UID, in cases like he wants to send two messages to the same twin dest and then wait for both responses on the same ret queue.

now when responses return, the client has no way to distinguish which response belongs to which message.

order can not be granted, as messages are sent with multi workers, also network routes can vary between the two requests.

so if we don't want to limit the client's ability to receive multi responses on the same return queue, we need to allow the client to set the message UID, then he can check this UID on the reply.

[muhamadazmy]

The use case you are already discussing is already possible. Please note the following

• the message ID must be unique because it's used internally for message routing. Two message with same ids on the same node will cause issues.
• While the client will not set an id (rmb does) the client CAN use the same return queue for all messages. This means that all his responses for all messages that use the same retuqueu will be received on that queue.
• To fix the issue about not being able to link which response belongs to which message. I suggest adding a new optional tag field on the message. The tag is transparent and has no effect on the routing but will be used to mark the message for sdk reference.