Fetch solver that created settlement transaction

[sunce86]

Description

A preparation to implement #2998 which will require sending multiple settle requests to drivers, and waiting for multiple settlement transactions.

In order to match settle requests with settlement transactions, we need solver that created the settlement transaction.

Changes

• Fetch solver from settlement event and use it to make sure it's the same as the driver reported solver address.

How to test

Existing e2e tests.

[fleupold]

I still think the key question of this entire epic is how will solutions be identified (I don't think it should be solver address but instead some committment on orders, prices, etc). Once we answer this question we can map a settlement we observe with a settlement that was promised.
Also, I don't think we should be reading the promised settlement from the DB (there is no need for this), it should be passed into the function that calls settle

[sunce86]

I still think the key question of this entire epic is how will solutions be identified (I don't think it should be solver address but instead some committment on orders, prices, etc). Once we answer this question we can map a settlement we observe with a settlement that was promised. Also, I don't think we should be reading the promised settlement from the DB (there is no need for this), it should be passed into the function that calls settle

I've commented on this question here: #2830 (comment):

We can match on orders since no common tokens are allowed to exist in winning solutions.

[m-lord-renkse]

why to move it out of the function? if so, please, conserve the function comment as this code is not trivial

[sunce86]

I felt like settle function is too short and there is a point in inlining the wait_for_settlement.

This becomes painful when we forward bunch of arguments to inner functions.

[m-lord-renkse]

So, IIUC, this PR is just to add the solver from the solution to the run loop and queries in order to adapt it for #2998, right?

[sunce86]

So, IIUC, this PR is just to add the solver from the solution to the run loop and queries in order to adapt it for #2998, right?

Yes. Not having too much impact except for debugging since settling is anyway done in background and runloop is early returned, so settling result doesn't have any impact on the runloop logic.

[MartinquaXD]

Change makes sense to me.

I still think the key question of this entire epic is how will solutions be identified (I don't think it should be solver address but instead some committment on orders, prices, etc).

I think it's reasonable to assume that solvers only submit one solution so I believe checking (solver_address, auction_id_bytes) should be sufficient. Should a solver decide to play games and submit something different they need to get slashed either way so I'm not sure there is much value in holding up the /settle call possibly because some amounts are every so slightly off for example.

Also, I don't think we should be reading the promised settlement from the DB (there is no need for this)

I see the argument that we would be able to recover all the necessary data from the network but unless I'm missing something this would then effectively mean we have to have 2 places to match settlements to auctions. Once in the post processing step (DB) and once in the autopilot. By calling the DB we reduce that to a single point.
Which admittedly comes with the downside of ensuring that the DB job ran before we check that the solution was found on every block but that seems reasonable to me.

And circling back to the point above: should we chose to match settlements to promised solutions differently (e.g. by orders and prices) I think we should do it in the DB and not in this PR.

Only not approving due to the the in-flight orders issue @squadgazzz pointed out.