auth: Add AzureSessionProvider and related types

[alexweininger]

Goals: improve structure of our auth package so it can be more easily consumed by partner extensions that don't necessary follow our tree view structure. This is specifically coming from Peter, who works on the AKS extension and basically wrote all of this code as part of their own migration off of Azure Account.

Putting this PR up so I can give feedback and ask questions easier as we iterate over this code.

[peterbom]

@peterbom could you describe how the AKS extension would utilize these changes? Would you just be instantiating a VSCodeAzureSessionProvider and ignoring VSCodeAzureSubscriptionProvider? Would you be instantiating both?

@alexweininger - yes, that's what I'm thinking: instantiating a VSCodeAzureSessionProvider and ignoring VSCodeAzureSubscriptionProvider

A quick summary of my reasoning:

• Consistency of use: It enables us to use the same pattern for interacting with ARM SDKs (getting credentials and instantiating clients), regardless of whether a command was launched from a TreeView containing subscriptions or from the command palette.
• Separation of concerns: I don't feel that subscriptions are conceptually tied to sessions/credentials, and when moving away from the Azure Account extension I reworked the treeview to that it only exposed persistent properties of resources like IDs and names, and not sessions/credentials (which I worried about getting stale). Since the equivalent of the AzureSessionProvider gets us credentials easily I don't think we'd have a big need for an AzureSubscriptionProvider.

[alexweininger]

yes, that's what I'm thinking: instantiating a VSCodeAzureSessionProvider and ignoring VSCodeAzureSubscriptionProvider

Great, that's what I figured. And I completely agree with your reasoning. I think other extensions like should do the same.

[alexweininger]

@peterbom When you have a chance, could you add me as a contributor to https://github.com/peterbom/vscode-azuretools/tree/experiment/session-provider? That you don't have to do all the changes yourself.

[alexweininger]

I originally wanted to try to get this PR in before we officially announce the Azure Account extension deprecation, but now I've decided to wait. Once announced, I'm expecting teams to come to us with specific asks and needs for their migration, and I'd like to make sure we cover those in this refactor.

I've gathered a list of all extensions that depend on Azure Account and I don't think as many will actually need these changes as I thought. Only 2-3 out of about 25. If my research is correct, and that's truly the case, then I'd like to hold off on putting these changes through. The added complexity of the session provider might not be worth it if only the 2-3 partners are depending on it, while 25 others only need a subscription provider.

[bwateratmsft]

I originally wanted to try to get this PR in before we officially announce the Azure Account extension deprecation, but now I've decided to wait. Once announced, I'm expecting teams to come to us with specific asks and needs for their migration, and I'd like to make sure we cover those in this refactor.

I've gathered a list of all extensions that depend on Azure Account and I don't think as many will actually need these changes as I thought. Only 2-3 out of about 25. If my research is correct, and that's truly the case, then I'd like to hold off on putting these changes through. The added complexity of the session provider might not be worth it if only the 2-3 partners are depending on it, while 25 others only need a subscription provider.

@alexweininger agreed, good plan. Those needing a session provider should also consider just directly using the account APIs provided by VSCode, these are more session-shaped.