Add a mechanism to prevent concurrent token refreshes

[lilpit]

When multiple different firebase services require a token refresh at the same time, multiple token refresh can be triggered at the same time inside the SecureTokenService.

This PR makes sure only one token refresh is happening at the same time

Discussion

• This is addressing Multiple concurrent token refresh calls on app launch #15474

Testing

• Added some unit tests to test concurrent reload behaviors
• Tested this branch in our sample project where we reproduce the issue -> the issue is gone
  Testing scenario:
• Open the sample app
• Wait for 1 hour for token expirtation
• Re open the sample app -> only one token refresh is performed instead of multiple one

API Changes

• No API changes

[gemini-code-assist]

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[ncooke3]

Thanks for the PR!

[ncooke3]

Suggested change

	/// Task { try await tokenRefreshCoalescer.coalescedRefresh(backend: backend, ...) } // 1
	/// Task { try await tokenRefreshCoalescer.coalescedRefresh(backend: backend, ...) } // 2
	/// Task { try await tokenRefreshCoalescer.coalescedRefresh(backend: backend, ...) } // 3
	/// Task { try await tokenRefreshCoalescer.coalescedRefresh(currentToken: token, ...) } // 1
	/// Task { try await tokenRefreshCoalescer.coalescedRefresh(currentToken: token, ...) } // 2
	/// Task { try await tokenRefreshCoalescer.coalescedRefresh(currentToken: token, ...) } // 3

[ncooke3]

What about calls within quick succession that have a different token?

Example

Task { try await tokenRefreshCoalescer.coalescedRefresh(currentToken: token1, ...) }  // 1
Task { try await tokenRefreshCoalescer.coalescedRefresh(currentToken: token1, ...) }  // 2
Task { try await tokenRefreshCoalescer.coalescedRefresh(currentToken: token2, ...) }  // 3

The last call has a different token so that would cancel out the first two calls? Was this a realistic scenario within your sample app?

[lilpit]

Good question !
In our sample app the refresh request would be executed multiple time with the same token (the one that expired)

Yeah requesting a different token would cancel the previous requests. Do you think the scenario you're describing could happen ?

[ncooke3]

IIRC, I don't think there are multiple access tokens, each with their own refresh lifecycle. I'll look within the SDK.

cc: @pashanka