Auto attach incoming message dispatch properties to outgoing

[danielmarbach]

Quick spike to automatically propagate incoming message dispatch properties to the outgoing messages. If we did this for real we probably would have to differentiate the dispatch properties that always need to be copied to all messages vs the dispatch properties that should only be copied when the incoming message is copied in the recoverability and audit contexts.

This way headers do not need to be polluted with transport-specific key-value pairs, the headers are not extended for information that is natively stored on the underlying transport message and the information is also preserved in the outbox.

ServiceControl could easily store this information in the metadata and bring it back when materializing the transport operations for staging and retries. Then no native information is lost anymore because the dispatcher can always map it from the dispatch properties, and during transition we don't duplicate the information to headers that is natively available on the underlying SDK type. The information is only persisted separately for external persistences like outbox and SC.

This would allow storing native attributes and preserve them in SQS. It would allow using native concepts like the message group id. In ASB we could store things like subject, session ID etc. and never lose it again.

Complexity like https://github.com/Particular/NServiceBus.AmazonSQS/blob/master/src/NServiceBus.Transport.SQS/Sending/MessageDispatcher.cs#L429-L436 would be handled in Core

[danielmarbach]

@mauroservienti @andreasohlund As a thought experiment, I did a quick spike floating incoming dispatch properties to outgoing operations natively in Core.

This would give the transport the possibility to serialize native information into dispatch properties and map it back out during dispatch to native properties. Core could take care of the rest. No more lossy conversion for audit and error dispatches and the possibility to float certain native data forward or other cases (see description).

This is not done and would require more thinking.

// cc @ngallegos @DharmishthaVPatel @bartekwasielak

[andreasohlund]

This would also allow us to support the outbox in native customization scenarios as well, right? (Allthough with a more retrictive API https://github.com/Particular/NServiceBus.Transport.AzureServiceBus/blob/master/src/Transport/Sending/NativeMessageCustomizationBehavior.cs#L20 )

[mauroservienti]

Nice!