feat: Allow multiple solution submissions for one auction

[fleupold]

Problem

We frequently see competing solutions in which some orders are matched in the first and some other orders are matched in the other solution. Currently we chose the single best solution from all candidate, potentially leaving order that had been matched unsettled. This can cause delay and increase the user's "time to happy moo"

Suggested solution

Allow mutually exclusive solutions (ie solutions that don't overlap in any order) to be settled in the same auction.

Additional context

This will have non-trivial impact on other parts of the protocol (e.g. solver payouts) so we should proceed with a lot of care. Maybe we can first experiment with this in sepolia to see which parts of the existing backend system would break and then coordinate with the remaining teams to see if there are issues with also enabling this in prod.

Acceptance criteria

There should be a way to configure the maximum number of solutions that can be settled per auction (default to 1 like today). If set to more than one, the top n solvers should receive a settle call.
Settlement indexing and all other post trade features (fetching trades, solutions, etc) should be working no n>1 as it is today.

[sunce86]

Tasks preferably implemented in a given order:

• Update database::settlements::get_hash_by_auction_id() - Get_hashes_by_auction_id implementation for multiple settlements #2976
• Redesign database table settlement_score to support multiple winners - New database tables for auction and solver competition #2980 [ ]
• Update database::settlement_observations::fetch() to return multiple settlement observations
• Update E2e::tests::database::most_recent_cip_20_data - [EASY] Update most_recent_cip_20_data #2997
• Update solver_competition::load_by_id() and load_latest_competition to return multiple entries. - Fix solver competition loading for multiple winners #3049
• OnSettlementEventUpdater alternative solution to detect settlements from another environment - Use blocks to determine other environment settlements #3053
• Add configuration parameter to autopilot for how much settlements per Auction are allowed - Multiple winners in autopilot #2996
• Update competition so that multiple winners are chosen - Multiple winners in autopilot #2996
• Update saving of competition to database - New database tables for auction and solver competition #2980
• Implement multiple settle requests on autopilot (and potentially on driver side if the same solver can have multiple winning settlements). - Multiple winners in autopilot #2996

[fleupold]

As for scope creep, can we agree that for the speed initiative we still want solvers to combine solutions as much as possible (that is each solver will only receive one settle call). I think this reduces scope and in the absence of the new fairness rule (which may disqualify batched bids) I don't think this is needed.

[fleupold]

I think the main thing I'm missing from a design perspective is how we are going to match solution candidates with settlement observations?
Will there be some aspect about the solution (like the orders that were promised, prices or similar) or some form of solutions id that needs to get encoded (similar to auction id) or will we match on msg.sender of the transaction?

If we told 3 solvers to settle and observe 2 settlements later on chain, how do we know which one is which?

[sunce86]

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

[sunce86]

Closing as implemented.