Pipe request_id of /settle call to ethrpc transport logic

[MartinquaXD]

Description

Follow up to #3243.
The previous PR had 2 problems that prevented it from actually piping the auction id to the X-REQUEST-ID header of RPC calls.

1. autopilot only set the auction_id as X-REQUEST-ID header on /quote and /solve calls but not on /settle calls.
2. since the introduction of the /settle queue in the driver there is background task that ultimately executed the RPC calls for submitting a transaction. And the task local storage of that background task was not set correctly.

Changes

1. autopilot now sets X-REQUEST-ID for /settle calls as well
2. driver reads request_id from task local storage and adds it to the struct it puts into the settle queue. When the background task picks up the struct from the settle queue it sets the task local storage to the struct's request_id value.

How to test

Added logs to the ethrpc http transport module to print the X-REQUEST-ID header it would set for the request. With this PR the auction_id finally started to appear in the RPC requests.
Tested with buffered HTTP transport (for public mempool submission):
Since I used the e2e test for submitting multiple winners 2 eth_sendRawTransaction requests for auction 482 got buffered into the same RPC call.

2025-01-21T12:03:16.625Z ERROR ethrpc::http: set request_id id="482:eth_sendRawTransaction(0,1)|6:eth_call(2..7)"

and unbuffered (for mevblocker submission):
In the unbuffered version we instead got 2 separate eth_sendRawTransaction calls for the 2 solvers. This time for auction 484.

2025-01-21T12:09:59.218Z ERROR /settle{solver="test_solver" auction_id=484}:mempool{kind="Mempool(MEVBlocker)"}: ethrpc::http: set request_id id="484" method="eth_sendRawTransaction"
...
2025-01-21T12:09:59.236Z ERROR /settle{solver="solver2" auction_id=484}:mempool{kind="Mempool(MEVBlocker)"}: ethrpc::http: set request_id id="484" method="eth_sendRawTransaction"

[MartinquaXD]

BTW piping the tracing labels through the code base is getting pretty messy. We should definitely consider introducing opentelemetry support which should take care of all that under the hood AFAIK. (probably modulo the http transport related logic)

[squadgazzz]

👍

[MartinquaXD]

Closed in favor of #3251