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:

• [x] Update database::settlements::get_hash_by_auction_id() - https://github.com/cowprotocol/services/pull/2976
• [ ] Redesign database table settlement_score to support multiple winners - https://github.com/cowprotocol/services/pull/2980- [ ]
• [x] Update database::settlement_observations::fetch() to return multiple settlement observations
• [x] Update E2e::tests::database::most_recent_cip_20_data - https://github.com/cowprotocol/services/pull/2997
• [ ] Update solver_competition::load_by_id() and load_latest_competition to return multiple entries. - https://github.com/cowprotocol/services/pull/3049
• [ ] OnSettlementEventUpdater alternative solution to detect settlements from another environment
• [x] Add configuration parameter to autopilot for how much settlements per Auction are allowed - https://github.com/cowprotocol/services/pull/2996
• [x] Update competition so that multiple winners are chosen - https://github.com/cowprotocol/services/pull/2996
• [ ] Update saving of competition to database
• [x] Implement multiple settle requests on autopilot (~and potentially on driver side if the same solver can have multiple winning settlements~). - https://github.com/cowprotocol/services/pull/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 on 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 in winning solutions.