oauth2 has a ReuseTokenSource (or ReuseTokenSourceWithExpiry) where you can pass the initial token and a interface implementation of Token().
That will save us from implementing all the locking involved, valid and expiry logic

All token-refreshing methods in oauth2 require client credentials to work and they use a refresh_token to do so. They are not usable for this use case on their own.

As another point, we want to default to the client-provided token only if cloud env is not set (because plugins don't have the expires_at field in their spec as they assume the user-provided token would be valid for the lifetime of the plugin). That's why the remoteToken exists, if cloud env is set we override the spec-specified token with a cloud one and can have the actual expiry timestamp.

... I'll check if something can be done within the limitations of the things I've outlined in the above two comments.

I don't think it saves us from anything, the code is simple and about the same as the official implementation. Wrapping it in another ReuseTokenSource will just make it complicated. Furthermore, removing expired will remove timeNow access and will make testing harder or slower.

All token-refreshing methods in oauth2 require client credentials to work and they use a refresh_token to do so. They are not usable for this use case on their own.

Looks like ReuseTokenSource doesn't use a refresh token it calls .Token() on the provided src interface https://github.com/golang/oauth2/blob/b52af7d5b4e39d5bb1ee067d8aa110fcce9e4cc7/oauth2.go#L310

You can even pass the initial token as nil if you'd like, e.g. ReuseTokenSource(nil, customTokenSourceThatGetsNewTokenFromCloud)

Refresh token logic is here https://github.com/golang/oauth2/blob/b52af7d5b4e39d5bb1ee067d8aa110fcce9e4cc7/oauth2.go#L250, it creates a tokenRefresher (which is an implementation of TokenSource interface).
What I'm suggesting is that we do the same with our own TokenSource interface implementation

if cloud env is not set (because plugins don't have the expires_at field in their spec as they assume the user-provided token would be valid for the lifetime of the plugin)

We can:

1. Set the expiry to a very long time in the future not in a cloud environment
2. Have our own TokenSource interface always return the client provided token not in a cloud environment

Done in 3e909a8