Restructure Azure backend into versions

[zalegrala]

What this PR does:

In #2882 we upgraded the SDK version for Azure. This started showing periodic segmentation fault errors in the Go runtime for unknown reasons. After a bit of research an no answers, here we resurect the original Azure backend code into a v1 package and move the new SDK into a v2 package behind a configuration flag. This will allow us to make a slower migration and gain some confidence about the approach and the new SDK before forcing production workloads onto the new code path.

Checklist

• Tests updated
• Documentation added
• CHANGELOG.md updated - the order of entries should be [CHANGE], [FEATURE], [ENHANCEMENT], [BUGFIX]

[joe-elliott]

I like the safety of this call. It gives us the chance to experiment with the new sdk to prove out stability given the current panics in CI.

Needs changelog/docs

cc @LasseHels

Heads up on this change. I believe (@zalegrala has been chatting with you so you're somewhat aware). Internally we are going to run the v2 sdk in our dev envs and on non critical components in prod. After we've gained some confidence in stability we can completely swap over to v2. Thank you for all your work here!

[LasseHels]

@joe-elliott @zalegrala Good call! We are excited to try this out in dev as well. The Tempo PVC bug is our most persistent bug, so we'll be celebrating when we finally don't have to nurse the PVCs anymore 🎉.

[zalegrala]

Nice that will be good. We'll be rolling this change out over the next few weeks and likely running a couple less critical components on the v2 work. Thank s for your efforts here. Based on the upstream Azure bug, it sounds like we only would experience the issue in testing, but I'd rather err on the side of caution.