Move support for Express/NonDurable messages down to the transport level

[andreasohlund]

As #4162 has highlighted supporting non durable messages across all transports is not possible since not all transports are able to provide it. To help guide users better we should have each transport that is capable of non durable messaging provide its own API to allow users to specify messages that doesn't need durability.

The plan is to:

• Deprecate the core Express attribute and convention
• Reintroduce the [Express] attribute and convention in a MSMQ package (when the transport is split out from the core this could live in there). We can then also tighten up the validation that eg. the queue needs to be created as non-transactional for "Express" to have any effect at all.
• Consider if we need this on the contract level or if a Send|PublishOptions.Express() is good enough
  • Perhaps a SendOption that allows Action<System.Messaging.Message> would be enough to start with? (as a catch all option since I'm pretty sure Express isn't widely used since it requires non transactional queues to be of any use)

Have the transports that truly support non durable message add native API's to allow for this. This would mean that we could use lingo that aligns better with the transport.

• RabbitMQ would provide a API to request "NonDurable" similar to MSMQ

@Particular/azure-service-bus-maintainers does ASB allow for non durable messages?
@Particular/azure-storage-queues-maintainers does ASQ allow for non durable messages?
@Particular/sqlserver-transport-maintainers sqlserver will not support this for now? (or until we consider non durable tables https://msdn.microsoft.com/en-us/library/dn511014.aspx )

[MarcinHoppe]

I agree there is not much value for SQL transport right now. We could do INSERTs and DELETEs with DELAYED DURABILITY = ON to somewhat simulate non-durable messages and gain a little bit of performance in non-DTC scenarios.

[SeanFeldman]

ASB doesn't have a concept of express messages, but express queues. What should be considered if we decide to do this:

• To support express messages, we'd need to make all queues express.
• Backwards compatibility - existing queues would not work with express
• And even with that, after a few seconds messages would still get persisted, as they'd normally would.

[andreasohlund]

ASB doesn't have a concept of express messages, but express queues

This is actually quite similar to MSMQ since express won't work unless your queues is "non transactional"

https://docs.particular.net/nservicebus/messaging/non-durable-messaging#effect-on-transports-msmq-extra-configuration-for-msmq

[Scooletz]

ASQ does not have a concept of express queues. Once you've got a response, the message is persisted. The only part that one could work with is the client side, for instance, skipping the awaits over some of the messages as described in Particular/NServiceBus.AzureStorageQueues#168 (comment) I see a little value in it though.