Improve interface for retrieving authentication sessions

[peterbom]

Is your feature request related to a problem? Please describe.

The recent issue #680 highlighted an ambiguity around the AzureSessionProvider interfaces.

Specifically, it is unclear whether the selectedTenant property is necessarily accessible without further user interaction. Internally (within the AzureSessionProviderImpl class) we try to ensure that it is immediately accessible. That means we can return a ReadyAzureSessionProvider with that property populated, and be reasonably sure it can be used immediately, without the user being directed away to a browser authentication tab.

The problem here arises from the fact that the selectedTenant property serves two purposes: to represent the user's selected tenant AND to indicate they are fully authenticated.

Additionally, the parameters for getAuthSession do not allow for specifying additional/different scopes. These are needed in two scenarios:

1. When using a graph client (or any client for endpoints other than ARM).
2. When specifying an Entra ID application other than the default VS Code one (which doesn't have delegated permissions for some graph-related requests relating to managing applications and service principals).

Describe the solution you'd like

I think there are two possible ways to resolve the ambiguity of the selectedTenant property:

1. Give up on the idea that 'ready' means 'no further user interaction', and instead interpret it as 'user is signed in and has selected a tenant, but further authentication may be required to access that tenant'.
2. Add an extra property (perhaps on the Tenant type) to indicate whether the user is fully signed in to the selected tenant.

The first option is technically simpler and so it makes sense to try that first. If it degrades the user experience somehow, we can use that as justification for the more complex option.

For the getAuthSession parameters, I'd like to make a change similar to that discussed here:

export type GetAuthSessionParams {
    applicationClientId?: string;
    scopes?: string[];
}

[peterbom]

It's uncertain whether a similar AzureSessionProvider class will make it into the azuretools library.

In case that does go ahead, it might make sense to adhere to the structure proposed there, so that we can swap the implementation at a later date with minimal refactoring.

That would entail separating the session provider from the tenant selection logic, which are currently bound together in our implementation. This is arguably worthwhile in its own right, and could serve as a model for the 2-3 other extensions which might want an abstraction over the VS Code API, but not necessarily the same tenant selection logic as us.

[peterbom]

Resolved by #695