Move from WindowsAzure.ServiceBus to Azure.Messaging.ServiceBus

[joelverhagen]

Address https://github.com/NuGet/Engineering/issues/5011

Summary of changes:

1. Remove WindowsAzure.ServiceBus dependency, add Azure.Messaging.ServiceBus dependency
2. Introduce IReceivedBrokeredMessage. This mirrors a similar split in the send and receive message models in the new SDK.
   • This is a better data model IMO since some things are immutable on received messages and the models can express that.
3. Add several shim-behaviors, to ensure full back-compat
   • Generate a random message ID on the client side (new SDK doesn't so this, partitioned topics require this)
   • Add support for sb://namespace/ style connection strings (old SDK supports it, new SDK does not)
   • Serialize message content using XML data contract. I dislike this but we must do this to handle messages sent by old SDK

Testing strategy:

1. Full deployment to DEV
   • Gallery, internal jobs, OSS jobs
   • Test send-receive compat (sender on new SDK, receiver on old SDK and vice versa)
   • Push steady stream of validations and reboot VMs (non-graceful message handling)
2. Full deployment in INT
3. PROD strategy:
   • Deploy single region of SB listeners and observe telemetry
   • Wait 48 hours
   • Deploy 2nd region of SB listeners
   • Wait 24 hours
   • Deploy gallery

[mariaghiondea]

Thank you for the work on this one!
Anything that we can do to prevent regressions, especially anything that would come up at runtime?

[joelverhagen]

Thank you for the work on this one! Anything that we can do to prevent regressions, especially anything that would come up at runtime?

I've updated the PR description with details. In short: full deployment of all SB-interacting component in DEV/INT prior to PROD (as expected) and a careful deployment in PROD where we move listeners slowly and services (i.e. senders = gallery) later.

[agr]

Feel free to ignore my comments, nothing important there.