Only stream 1 /solve request body in driver

[MartinquaXD]

Description

Because the driver serves multiple solvers it receives a bunch of duplicated /solve requests. There is already logic to deduplicate the pre-processing but we there is still one part left that's done unnecessarily often: streaming the HTTP body.
Streaming the http body currently takes up to 700ms which is surprisingly slow considering that the HTTP request goes from one k8s pod to another and not via the public internet.
I suspect the problem is that we are actually streaming ~10MB /solve requests 23 times in parallel (numbers from mainnet).
#4159 introduced a new header (X-Auction-Id) that can be used to detect which auction a request is related to without having to stream the entire body.

With this change everything but prioritizing (i.e. sorting and allocating balances for orders) and the serialization of the driver's /solve request will be de-duplicated. That means adding more solvers to the driver will be less costly.
If we consider enforcing the same prioritization logic for ALL solvers that could also be de-duplicated leading to more or less 0 overhead for adding more solvers to the same driver.

Changes

• inspect X-Auction-Id header to figure out whether we have to process the request or just await an existing pre-processing task

Note that this change must be released AFTER https://github.com/cowprotocol/services/pull/4159`. The reason is that k8s first rolls out driver pods so there would be a period where the old autopilot is still sending requests without the X-Auction-Id header.

How to test

e2e tests

[gemini-code-assist]

Code Review

This pull request aims to optimize /solve request handling by using the X-Auction-Id header for deduplication. However, the current implementation introduces a cache poisoning vulnerability due to trusting the header without body verification, and a Denial of Service (DoS) risk by holding a global mutex during asynchronous body streaming. Furthermore, there's a critical backward compatibility issue where requests missing the X-Auction-Id header will fail, impacting rolling updates. These security and compatibility concerns need to be addressed.

[jmg-duarte]

At this point, aren't we always sure the auction ID is positive? Couldn't we use u64 and start slowly migrating to the more correct number (as it prevents a whole range of invalid numbers)?

[MartinquaXD]

I agree with the idea but I think the migration from i64 to u64 should probably happen in one swoop given that we don't actually see any negative numbers in practice so there is no reason to be slow and methodical IMO.

[squadgazzz]

Great improvement!