Enhance and Clarify use of JWT Token Introspection Policy

It is possible to have a basic set of attributes encoded into a JWT token and have a richer, enhanced set of attributes returned from a token introspection endpoint.

If the JWT Token Introspection policy captured and returned the token introspection response and made this data available for use in context with other policies in the chain resource servers could then decide, for example, whether 1) to validate the token signature and introspect it directly or 2) to pass the token to the introspection endpoint for validation and retrieval of additional info to examine and/or trigger additional logic. 

It doesn't appear that the JWT Token Introspection policy allows for use of the token introspection response data by other policies in the chain.  This policy could be enhanced to make use of it (with potentially minimal effort - TBD).  

Additionally, we would like clarity in the documentation on the value of the Token Introspection policy.  In working with 3scale, our understanding is that there is a local signature check that is implicit in configuring OIDC authorization within the solution.  When using Token Introspection the token is validated once for 3scale Auth purposes and then the Token Introspection policy would send it to the introspection endpoint for additional validation?  We aren't clear on what use case(s) this policy is intended to support?  

We are also interested in how Token Introspection caching interacts with 3scale Auth caching?  Could 3scale Auth caching allow a request through that the Token Introspection policy needs to validate?  Are there best practices for configuring these two cache settings so that they work optimally together?