Cache tokens by specified environment, not by OIDC Discovery

[rayluo]

@abhidnya13 please help verify this, both by re-running our BF/FF manual tests, and by code review, to see whether this can address the issue we found recently.

[abhidnya13]

I reviewed this PR by testing BF/FF test cases, and the error of not finding tokens in cache is now gone, so it looks good from migration perspective.
Other than that, it however change the normal cache look up behavior? Are there any concerns regarding that? If two apps are storing token App1 has an input authority of env1 in cache and App2 has env2 (app using some other MSALs storing this based off the actual authority value from service and not the user). MSAL python in App1 wont be able to get the env2 token stored by app2 even if it is a valid token to be used.

[rayluo]

Excellent question. We need to come up more and more of these kind of different scenarios to help us evaluate this PR.

In this particular case that you brought up, please help me stress-test my following assumption. The findings of this migration test makes us realize that, MSAL Python (or at least, its get_accounts() and acquire_token_silent() parts) never worked for a corner case when the app-specified authority env1 does not match with the OIDC-discovered endpoint env_one. In other words, it would only fully work when env1 and env_one are identical (true or false?). In that case, there shouldn't be any tangible difference when we switch the token cache from env_one to env1 this time.

W.R.T. app1 with authority env1 and app2 with env2 (and assuming their OIDC-discovered endpoints are also env1 and env2, respectively), were they previously able to share token cache with each other in the first place?

[abhidnya13]

LGTM

[rayluo]

Thanks. We are merging this PR. Once merged, you would then need to use 1.5.0 version to reproduce the pre-adjustment behavior, should we need to mimic that situation again during our recent migration tests.