Migration plan to move towards new Azure Service Bus SDK

[stijnmoreels]

What is your idea/suggestion?
We should determine what is supported in the new Azure Service Bus SDK before we move towards it.
Here's the migration guide which describes how the move towards this new SDK is supposed to happen.

These are the features that is being used by the current Azure Service Bus library:

• Registering callback function to process the message
• Completing a message (with lock token)
• Abandoning a message (1. with lock token and 2. with lock token and message properties)
• Dead lettering a message (2. with lock token and 2. with lock token, reason, and description)
• Auto-complete a message after it's being received
• Setting maximum concurrent message can be actively processed
• Registering Azure Service Bus plug-ins

Currently, these features are supported in the new Azure Service Bus SDK:

Feature	Current SDK	New SDK
Registering callback	✔️	✔️ : via the ServiceBusProcessor or `ServiceBusReceiver
Completing message	✔️	✔️ : via the ServiceBusReceiver (different signature)
Abandoning message	✔️	✔️ : via the ServiceBusReceiver (different signature)
Dead lettering message	✔️	✔️ : via the ServiceBusReceiver (different signature)
Auto-complete message	✔️	✔️ : via the ServiceBusProcessor options
Max concurrent calls	✔️	✔️ : via the ServiceBusProcessor options
Registering plug-ins	✔️	❌: supported in next release issue tracking

[tomkerkhove]

Thanks for the thorough overview, I think we should go with it and clearly document it in the new release notes that plug-ins are no longer supported and why.

[stijnmoreels]

I'll have already worked on this, but will wait until #170 and #141 are merged as they are both major changes.

[fgheysels]

Is there any news on this ?

[stijnmoreels]

This was done here: #175 together with the message routing extraction.