Upgrade jwt_authorizer to axum 0.7

[dsgallups]

This is some work done to update jwt_authorizer to axum 0.7. In the process, the ReqBody generic was removed in several places, as axum::extract::Request now has a default associated type.

[cduvray]

Thx for the PR, tonic (feature) is not compiling, I think the update of tonic to hyper 1.0 is needed.
Waiting for hyperium/tonic#1579

[dsgallups]

Thanks! The other thing is that you will notice your test minutes have mysteriously vanished... in oidc.rs line 27 calls discovery_url(issuer)?, which actually results in
Ok(Url { scheme: "http", cannot_be_a_base: false, username: "", password: None, host: Some(Ipv4(0.0.0.0)), port: Some(44281), path: "/.well-known/openid-configuration", query: None, fragment: None }). This leads to a hang when calling send() on client, because it appears that this host actually isn't instantiated...

Would this be due to tonic as well?

Edit: As @cduvray pointed out, this was not the problem. The problem was that the standard listener was in blocking mode. This lead to an asynchronous polling issue because the listener would continuously block the thread until all I/O operations completed...which, they never do.

[cduvray]

Here you should use the listener from the line 69, I think creating a new listener on the same port makes the tests stuck.

[dsgallups]

Resolved by making the std listener non-blocking...the integration tests should no longer hang! Much appreciated for figuring this out!

Reference: tokio docs

[cduvray]

Here I think you could call call() directly on as_service() (type RouterAsService).

[dsgallups]

I'll squash several of the prior commits and push this change when the tonic upgrade is complete.

[dsgallups]

It seems like the upgrade in tonic is slow progress...hyperium/hyper#3461 is blocking hyperium/tonic#1579, which can't occur until the next version of hyper is released. Wondering if you would consider feature gating the axum version based on use of tonic, or is that a horrible idea?

[cduvray]

I am not sure to understand what you mean by feature gating (tonic is already behind a feature switch).
I tried to move the tonic dependent code into a separate crate but I am blocked by the fact that From cannot be implemented for types from another crates. (impl From<AuthError> for Response<tonic::body::BoxBody> {...}).

[dsgallups]

My mistake! What I meant to say is you could make the version of axum dependent on whether the tonic feature is enabled. You've made more sense of the situation than me. If you choose to make a separate crate for tonic, then that would basically mean you'd have to ctrl+c/ctrl+v large swathes of the implementation, including AuthError. The alternative (and what I meant) is to set axum = 0.6.20, etc. when the tonic feature is enabled. However, that solution basically would result in the same costs, just in the same crate.

Alternatively, could just wait another month or so hahaha...I'll do what I can to get tonic to http 1 in the meantime.

Please let me know what you want to do, and I can create an according PR/work with you in tandem if you find it useful/necessary to separate versions between tonic and axum. Could also tackle #43 with this approach.