Use explicit message settlement via ServiceBusMessageActions

[andreasohlund]

This uses message actions to explicitly control message settlement, including the ability to DLQ messages and perform other advanced operations that are only available via the actions.

This PR also:

• Removes support for the ASB transport legacy body format
• Require message ID to be set, similar to the transport
• Align upconversion of message properties to headers with the ASB transport
• Support explicit DLQ requests via recoverability action
• DLQ messages when OnError fails with non-transient exception

[andreasohlund]

@danielmarbach ready for a initial review, some todos left in code for us to discuss

[andreasohlund]

@danielmarbach addressed your comment, there are a few things that needs to be discussed, left those as TODO's in the code

[andreasohlund]

@danielmarbach ready for final review

[danielmarbach]

In the transport, we wrap things we more try catch inside and log statements. Worth doing something similar? Doesn't have to be an extension method thught

https://github.com/Particular/NServiceBus.Transport.AzureServiceBus/blob/e844c7cde49682c0010f309ecfc9eabd74dcf5f8/src/Transport/Receiving/ProcessMessageEventArgsExtensions.cs#L72

[danielmarbach]

As far as I understand there are restrictions on how much data we can pass. So I wonder if we should do the following:

DeadLetterReason = ex.GetType().FullName
DeadLetterErrorDescription = first 1024-2048 chars of ex.Message

and then set the regular NServiceBus Exception headers like core would do because then things are already in the right shape and if that fails just the reason and the description and if that fails nothing else. Then in the best case you always get some extra useful information but in the case we have a message that is close to the message size restrictions we can still dead-letter things properly

[danielmarbach]

Also should we allow modifying the source or should we keep that auto assigned by the service?