Log solve request data transfer

[MartinquaXD]

Description

Some solvers reported that some requests come significantly delayed (judging by the auction deadline). Currently we have no way to distinguish between receiving the start of the /solve request and streaming the actual data.
This PR makes this possible by making the solve handler take a raw http request and stream the body afterwards.

Changes

Instead of:

1. collecting the whole body into a String (including utf8 check)
2. logging that we received a request
3. putting that String into an Arc to make copying it cheap
4. deserializing the string into a SolveRequest

We now do:

1. receive raw http request
2. log that we received it
3. stream the body into a cheaply copyable Bytes type
4. log how long the data transfer took
5. deserialize raw bytes into SolveRequest

Since handling the raw request seems to bypass axum's request size checks I did it manually for this endpoint.

How to test

Existing tests should suffice

[gemini-code-assist]

Code Review

This pull request refactors the /solve endpoint to measure the duration of request body data transfer, which helps in diagnosing reported delays. The implementation correctly changes the endpoint to accept a raw HTTP request and streams the body to hyper::body::Bytes while timing the operation. However, this change introduces a critical security vulnerability. By processing the raw request body without a size limit, the service is exposed to a Denial of Service attack via memory exhaustion from an overly large request payload. My review includes a comment with a suggested fix to mitigate this vulnerability by applying a size limit to the request body.

[squadgazzz]

LGTM. Just a nit.

It smells like a gRPC API is a better successor for this communication, since I assume a lot of data are bytes-related in any case.