Add message UUID so that we can follow e2e flow

[drasko]

Add UUID to each message that flows though Mainflux so we can log and follow the flow.

For RewMessage UUID field with be UUIDv4. For Message UUID can be <parent_uuid>.<local_increment> format - for example <parent_uuid>.0, <parent_uuid>.1 and so on - because RawMessage is de-aggregated locally in normalizer.

[drasko]

@srados please take this issue with high priority, so that we can release 0.7. @anovakovic01 please help on this issue.

[nwest1]

Sorry - didn't find this issue when I searched.

using a uuid would adhere to the similar opentracing format, so that would be perfect: https://github.com/opentracing/specification/blob/master/rfc/trace_identifiers.md#trace-context-http-headers

Similar to opentracing, I would ask that the ID be able to be set as an input field (or header?) so that correlation could accomplished across upstream systems.

[drasko]

@srados while on this, please take a look at Jaeger as well - there is go-kit support already: https://github.com/go-kit/kit/tree/master/tracing#opentracing

We should use this opportunity to align as much as possible to https://opentracing.io/specification/ and make implementation future proof.

Also, please investigate if something other should be changed/added to adhere to the standard.

[ghost]

using a uuid would adhere to the similar opentracing format, so that would be perfect: https://github.com/opentracing/specification/blob/master/rfc/trace_identifiers.md#trace-context-http-headers

Similar to opentracing, I would ask that the ID be able to be set as an input field (or header?) so that correlation could accomplished across upstream systems.

@nwest1 header would be ok for HTTP and gRPC however, we also have MQTT and WS that need to receive the correlation ID from upstream. What is your opinion on that?

[nmarcetic]

PoC with opentracing integration is in WIP. Moving this to 0.9