Upgrade to axum 0.7

[Turbo87]

This PR upgrades our projects to axum 0.7 and hyper 1.x.

The changes on the axum side are described by https://tokio.rs/blog/2023-11-27-announcing-axum-0-7-0

Unfortunately there appears to be no way to adopt most of these breaking changes incrementally, so this PR has gotten rather large. The three main changes are:

• bin/server.rs is rewritten based on https://github.com/tokio-rs/axum/blob/axum-v0.7.2/examples/graceful-shutdown/src/main.rs and https://github.com/tokio-rs/axum/blob/axum-v0.7.2/examples/serve-with-hyper/src/main.rs
• the generic B parameters are removed where necessary
• the implementation of the BytesRequest struct needed to be adjusted, but the test code stayed the same to verify the correctness of the changes

[syphar]

Just a note, I found that the graceful shutdown impl felt a little complex in the example, and wanted to see if tokio-rs/axum#2398 lands quickly enough

[Turbo87]

@syphar thanks for that link. it would certainly make this a lot easier... I'm not sure whether that supports ConnectInfo though?

[LawnGnome]

Having just gone through this with another project, this LGTM, but I'd be so much happier if we didn't have to do the graceful shutdown dance in our own, non-library code. (Obviously nothing we can do about that right now.)

I think the key here is going to be testing this pretty thoroughly on staging — areas in particular I think we'll want to poke at are behaviour under load and that service restarts still work reliably. (I know this is basically all taken verbatim from the example, and it all reads fine to me, but they're the areas I'm a little nervous about, personally.)

[Turbo87]

behaviour under load

I've tested it on staging using ApacheBench and the numbers didn't look significantly different before/after deploying this branch. The production dyno setup is a bit different to staging, but it looks like performance should be roughly similar to before.

service restarts still work reliably

I've used heroku restart -a staging-crates-io and according to the logs the graceful shutdown worked as intended and the download counters were flushed before exiting the process.