Make portalocker optional

[rayluo]

This is currently an experimental PR. It will not be merged, not until we receive some test feedback. To beta test this PR, you will need to pull it from its feature branch.

Usage: There is no API change. MSAL EX will automatically utilize portalocker when portalocker is available in current environment, and switch to a new portalocker-less implementation otherwise.

Note:

• A lock mechanism is only used to guard against garbled data due to concurrent read/write. A lock mechanism in itself does not make the higher level application more or less performant. When your app is overloaded, previously (i.e. before this PR) you will see portalocker.exceptions.LockException which means the locking mechanism is doing its job. After this PR, under the same heavy load, you will see LockError instead, which also means the new lock mechanism is functioning.
• Test automation currently fails, because keyring daemon no longer works. It used to work even in headless test environment. We will look into it at a later time. But this should not affect or block the beta testing of this PR.
• UPDATE on Dec 2024: This PR has been used internally for 2+ years without any issue. Thanks @bebound for testing!

CC: @jiasli

[jiasli]

Well, Azure CLI doesn't really need such a complex lock at the comment. Previously ADAL didn't have locking mechanism and worked mostly fine.

[rayluo]

Fair point. But if the current PR's non-portalocker lock is harmless, then we might as well just use it.

We are open to the dummy lock idea, too. We may work on it at a later time. It can be done, but it is more work, in terms of needing to expand the current MSAL EX api to allow a "no lock" option. (The current file-based lock, on the contrary, is a drop-in replacement for portalocker, and keeps the MSAL EX api intact.)

If the file-based lock does not work well for Azure CLI on SAW, we will prioritize the dummy lock work accordingly.

[rayluo]

See this comment on how to test this PR.