Cache result of IntrospectionTokenVerifier

[jhmartin]

Enhancement

IntrospectionTokenVerifier appears to reach out to the introspection endpoint on every client call. Given that none of the inputs have changed, and the expiration is known already, this puts excessive load on the authentication server to get the same answer. I understand the need to handle situations like revocations, so suggest that the mechanism support a configurable cache with a default cache timeout somewhere in the range of 60-300 seconds. This reduces the load from the magnitude of one-introspection-per-client-call to close to one-introspection-per-client-conversation. This may also improve the performance of FastMCP as it will not have to wait for a potentially slow authentication reply on each client call.

The value would ideally be stored in a configurable KV store in the same way as the OIDCProxy mappings; a redis that belongs to FastMCP is likely going to be more performant and network-close then a central auth server.