Support application/jwt in userinfo endpoint

[sergei-maertens]

Closes #517

This is an initial draft to spark discussion about implementation details.

Changes:

• Refactored the JWS verification into a generic helper - the goal is that the middleware methods are backwards compatible
• Added (partial) handling for application/jwt processing in the userinfo endpoint

Topics to discuss:

• test failures due to missing Content-Type header -> can we use a utility like vcr.py to record real requests instead of using unittest.mock / request mocking approaches? My experience is that those tools are very fragile
• I have a keycloak setup that can be added to the docker-compose which is configured for application/jwt - this is a powerful test setup with vcr.py from the above bullet
• How do we handle keys that are not loaded from a JWKS endpoint? I think a new setting would be relevant, but is that even a case you want to support and/or is used in real deployments? Looking at the code again, I'm not sure that HMAC 256 is even configurable?
• I've used type annotations because they help me write better code - some maintainers have strong opinions about these, just let me know your position about this and I'll adapt.
• Is this the right direction? It works like a breeze for us in our downstream library, but I'm open to feedback of course
• How do you feel about block-listing algorithm none?
• I looked into re-using parse_www_authenticate_header for the content type header processing, but it kinda borks on a value like application/json; charset=utf-8, so instead I use the (private) utility from the requests library which can be controversial. I don't trust myself enough to correctly and safely parse HTTP headers :grimacing:

[ikarius]

Seems legit for the handling of the application/jwt content-type. We stumbled on this issue where JWT content was in binary/byte array form, and the userinfo response was impossible to decode (because not in standard JSON).