Switch to MSAL 1.27+'s TokenCache._find()

[rayluo]

This PR will fix #127 . The fix will be shipped as MSALEX 1.2.0a1 within this month. And then next month both MSAL and MSAL EX will rename the affected function from _find() to iter().

CC @jiasli

[jiasli]

And then next month both MSAL and MSAL EX will rename the affected function from _find() to iter()

You may choose other names as well. This is just an idea that pops up in my mind.

[bgavrilMS]

@rayluo - how to avoid this type of regression in the future? Would it make sense to move the logic in this repo to the main MSAL repo? (we have done this in MSAL Java and MSAL .NET already - it also reduces the number of builds we need to look at).

[rayluo]

@rayluo - how to avoid this type of regression in the future? Would it make sense to move the logic in this repo to the main MSAL repo? (we have done this in MSAL Java and MSAL .NET already - it also reduces the number of builds we need to look at).

I'm afraid merging repo would not be a good option for Python. Nowadays, all interop layers of Python (such as the PyMsalRuntime package) would ideally be implemented with different technology which requires different pipelines anyway. Might as well leave them in a self-contained, separated repo.

Good news is we have lighter weight approach to guard this. Previously I did not anticipate API-level change in token cache (which never happened in the last 5+ years), so I did not setup nightly builds to test it with MSAL's dev branch. My bad. We shall do it this time, and it shall be sufficient.