feat(correlation): add open-telemetry as msg correlation scope

[stijnmoreels]

Introduce OpenTelemetry as a concrete implementation of an Azure Service Bus message correlation scope for the message pump, by introducing a new package called Arcus.Messaging.ServiceBus.Telemetry.OpenTelemetry that provides an extension on a message pump registration setup.

This PR provides concrete implementations with a new interface called IServiceBusMessageCorrelationScope and also updates the feature documentation to accompany this correlation option.

Note

Currently, the message pump still uses the deprecated MessageCorrelationResult to minimize the PR changes. This can later be either removed, or its content be moved to a new Arcus.Messaging.ServiceBus.Telemetry.Serilog package, if we want users to keep using the Serilog setup.

Relates to #464

[netlify]

❌ Deploy Preview for arcus-messaging failed.

Name	Link
🔨 Latest commit	fe3ecda
🔍 Latest deploy log	https://app.netlify.com/projects/arcus-messaging/deploys/69314d59f758ff000832ca34

[stijnmoreels]

Messaging is currently only 'Experimental' within OpenTelemetry. Once that is 'stable', we can again remove this one.

Best that we also check this in an existing project, how the transaction-link looks like as it might miss some additional tags... These tests only verify the producer-consumer parent/child relationship.

[fgheysels]

Note

Currently, the message pump still uses the deprecated MessageCorrelationResult to minimize the PR changes. This can later be either removed, or its content be moved to a new Arcus.Messaging.ServiceBus.Telemetry.Serilog package, if we want users to keep using the Serilog setup.

Relates to #464

I would be in favor of creating the Arcus.Messaging.ServiceBus.Telemetry.Serilog package. But, would that imply that, in order to have observability, a user of Arcus has to explicitly install / use one of these 2 packages. Seems like this is something that must be (very) clearly documented.

[fgheysels]

Thanks for the effort, just a few suggestions.
I'd be happy to test this in a real-life project.

[fgheysels]

Maybe we should make this a little bit less technical ?
Just a suggestion:

Arcus.Messaging makes it possible to make it visible in a logging system like Azure Application Insights, what happens when a message is received from a Service Bus topic or queue.
Below, you will find the different options that are supported to enable ServiceBus request tracking. When this is enabled, Arcus.Messaging will log a request operation for every message that is received from Service Bus and all traces and interactions to dependent systems that happen during the processing of that message, will be logged as children of this request operation.

[stijnmoreels]

Suggested change

	The following correlation systems are available when registering the message pump. These systems will use the incoming Azure Service Bus message to start a request operation. A `MessageCorrelationInfo` model is passed to your registered message handlers, which represents the current request operation. All interactions to dependent systems should be children of this operation for a transactional service-to-service relationship.
	Arcus Messaging makes it possible to make it visible in a logging system like Azure Application Insights, what happens when a message is received from a Service Bus topic or queue.
	Below, you will find the different options that are supported to enable Service Bus request tracking. When this is enabled, Arcus.Messaging will log a request operation for every message that is received from Service Bus and all traces and interactions to dependent systems that happen during the processing of that message, will be logged as children of this request operation.

[fgheysels]

I remember that I found it a bit cumbersome to understand where 'Process' was coming from, when I initially started using Arcus.Messaging.
When you do not explicitly override the OperationName when configuring Arcus.Messaging, you see these 'Process' operations popping up in AppInsights. I'd suggest that we use a default-value that makes it a bit more obvious where this is coming from ?
Maybe something like Arcus.Messaging Process or ServiceBus Message Processing , idk.

[stijnmoreels]

I agree, I like it that it would be defaulted to something Service Bus specific.

[stijnmoreels]

Suggested change

	private string _operationName = "Process";
	private string _operationName = "Service Bus message processing";

[stijnmoreels]

Note
Currently, the message pump still uses the deprecated MessageCorrelationResult to minimize the PR changes. This can later be either removed, or its content be moved to a new Arcus.Messaging.ServiceBus.Telemetry.Serilog package, if we want users to keep using the Serilog setup.
Relates to #464

I would be in favor of creating the Arcus.Messaging.ServiceBus.Telemetry.Serilog package. But, would that imply that, in order to have observability, a user of Arcus has to explicitly install / use one of these 2 packages. Seems like this is something that must be (very) clearly documented.

Yes, it is part if the migration guide already and will update further as soon as that Serilog package is there.