feat: drop cachetools dependency in favor of simple local implementation

[akx]

This PR drops the dependency on cachetools, which was only used for its LRU cache class, in favor of a simple local implementation.

This should have a small but positive effect on many downstream users given how many times this library is downloaded per day.

[clundin25]

Thank you @akx. Is using the standard library a reasonable alternative? https://docs.python.org/3/library/functools.html#functools.lru_cache

[akx]

@clundin25 Unfortunately not. The transparency of a lru_cached function is not really compatible with how the client code here is e. g. doing if foo in cache:.

[akx]

@clundin25 Is there anything I can do to help this move along?

[westarle]

How big is the change to update the client code so it can use the standard library and avoid maintaining this implementation?

/cc @sai-sunder-s

[akx]

How big is the change to update the client code so it can use the standard library and avoid maintaining this implementation?

Sorry, I wasn't sure whether that was directed at me or the person cc'd.

Not trivial, since it depends on being able to introspect the cache entry before deciding whether it's usable. lru_cache does not expose such a mechanism (nor being able to replace a single key from the cache, which is also required).

token, expiry = self._cache.get(audience, (None, None))
if token is None or expiry < _helpers.utcnow():

[akx]

Rebased. Is there anything I can do to help this move along? cc @westarle, @clundin25.

[akx]

Rebased again. Could this be moved along?

[zladovan]

It starts to be more useful now, as there is new major update of cachetools 6.0.0 and it's not possible to use it together with current google-auth.

[akx]

Rebased. Anything I can do to move this along (cc e.g. @clundin25)?

[akx]

Rebased (post #1773 merge).

[SchubmannM]

Would be great to get this is as indeed it's blocking other projects from updating cachetools beyond 6.0.0