Failure fetching any given access token should not throw OauthClient init

[amcclain]

Both MsalClient and AuthZeroClient call fetchAllTokensAsync() within their init methods.

That method loops through all configured access tokens to fetch those, then makes a call to fetch the id token we then expect to use for app-level auth. If any one of the configured access tokens fails, the entire init will throw and the user will be locked out of the app, even if that access token was not essential to the app functioning, or at least was not needed for the user to authenticate to Hoist. In particular would not want any failure to obtain an optional access token to block login to Admin Console.

We could generally catch access token fetching during init and provide a new way for admins to configure a token as essential/required, indicating that it should throw startup.

[amcclain]

Wondering if we should also consider expanding our access token "spec" to indicate if a token should be fetched eagerly at init time, or otherwise provide some way to customize. We have some scenarios where users of an app will only need an access token if they visit a particular module or issue a particular query. Not all users will have the roles required to do that - those tokens are N/A to those users.

Main motivation here is to not have to configure multiple oauth client instances, and instead use the single main authmodel instance. (Important qualification is that, for the proposed case, the alternate/optional tokens are for APIs within the same tenant, and can technically be obtained by a client that's configured to provide primary app-level auth)

This could be a distinct ticket - stashing it here and happy to discuss when we are ready to engage with the above, or the relevant client projects push on this further.