Reimplement sell=buy PoC PR

[m-sz]

Sell=buy token initiative

The ability to swap the same token pairs unlocks the potential for CoW to generally become a transaction relay service. This feature will allow users to execute pre- and post- interaction hooks as gasless transactions. The overall implementation has certain caveats:

• Each settlement has to go through the settlement contract anyway, so the sell=buy token transactions would require users to send X amount of sell token and receive X - cost of the token back. It is not realistic, with the current state of GPv2 contract for the user to just send the cost amount and save on gas this way.
• The solvers can really compete only by batching to save on gas costs
• There is little incentive for this feature to be supported by other solvers, but having this support in baseline solver could generally be enough.

Lift restrictions on sell=buy token

Based the changes on https://github.com/cowprotocol/services/pull/2513/files, adapted to current state of the codebase.

• Adds a command-line argument to the orderbook API to allow for same sell and buy token swaps. The SameBuyAndSell token error is not raised in that case
• Adds e2e test case that checks if sell=buy quoting and orders are possible
• Liquidity fetching happens only if the sell and buy tokens are different
• Relaxes the invariant on Tokens struct to allow for same token pairs
• Minor tweak to Justfile to allow for custom filtering and extra args to nextest

Based on input from @fhenneke:

• Adds a short-circuit behavior for solver to return empty route in case sell=buy
• Returns sell and buy assets directly when solving for empty route

The test case test_execute_same_sell_and_buy_token currently fails because despite creating an order with the same sell and buy token (the deployed token's address is 0x68b1d87f95878fe05b998f19b66f4baba5de1aed), the buy token becomes 0x5fbdb2315678afecb367f032d93f642f64180aa3 when order is considered for solving in an auction. Working on resolving that.

[squadgazzz]

I think this PR needs to be converted to a draft, since more changes are expected. @m-sz , is that correct?

[m-sz]

Yep, had a bunch of 1:1s and will be adding feature flag to the whole change to control it in orderbook.

[m-sz]

I have updated the PR with CLI argument to orderbook to allow for same sell and buy tokens.
Changes to baseline solver, to support those transactions will come in a separate PR.

[github-actions]

This pull request has been marked as stale because it has been inactive a while. Please update this pull request or it will be automatically closed.

[squadgazzz]

What happens if we place a buy order with the same tokens? Do we need to support it? We should either decline such orders or cover this case with e2e tests.

[extrawurst]

@squadgazzz for now sell order is enough for s&b, buy-orders only relevant for a later use-case of programmatic orders (see discussion).
@m-sz lets just block buy-orders for now.

[squadgazzz]

Why is this change required?

[m-sz]

Further down in the sell=buy unit tests I reuse the bad token detector.

[squadgazzz]

Emptiness validation seems redundant here. It would make sense to check the route.input() value, or just map it.

[m-sz]

Sure! Thanks.

[squadgazzz]

This logic also looks a bit awkward.

Suggested change

	if !route.is_empty() {
	interactions = route
	.segments
	.iter()
	.map(|segment| {
	solution::Interaction::Liquidity(Box::new(
	solution::LiquidityInteraction {
	liquidity: segment.liquidity.clone(),
	input: segment.input,
	output: segment.output,
	// TODO does the baseline solver know about this
	// optimization?
	internalize: false,
	},
	))
	})
	.collect();
	gas = route.gas() + self.solution_gas_offset;
	input = route.input().expect("route is not empty");
	output = route.output().expect("route is not empty");
	} else {
	// Route is empty in case of sell and buy tokens being the same, as there
	// is no need to figure out the liquidity for such pair.
	//
	// The input and output of the solution can be set directly to the
	// respective sell and buy tokens 1 to 1.
	interactions = Vec::default();
	gas = eth::Gas(U256::zero()) + self.solution_gas_offset;
	(input, output) = match order.side {
	order::Side::Sell => (order.sell, order.buy),
	order::Side::Buy => (order.buy, order.sell),
	};
	output.amount = input.amount;
	}
	interactions = route
	.segments
	.iter()
	.map(|segment| {
	solution::Interaction::Liquidity(Box::new(
	solution::LiquidityInteraction {
	liquidity: segment.liquidity.clone(),
	input: segment.input,
	output: segment.output,
	// TODO does the baseline solver know about this
	// optimization?
	internalize: false,
	},
	))
	})
	.collect();
	if !interactions.is_empty() {
	gas = route.gas() + self.solution_gas_offset;
	input = route.input().expect("route is not empty");
	output = route.output().expect("route is not empty");
	} else {
	// Route is empty in case of sell and buy tokens being the same, as there
	// is no need to figure out the liquidity for such pair.
	//
	// The input and output of the solution can be set directly to the
	// respective sell and buy tokens 1 to 1.
	gas = eth::Gas(U256::zero()) + self.solution_gas_offset;
	(input, output) = match order.side {
	order::Side::Sell => (order.sell, order.buy),
	order::Side::Buy => (order.buy, order.sell),
	};
	output.amount = input.amount;
	}
	}

[squadgazzz]

Also, let's avoid this style with declaring empty variables. Not really an idiomatic approach.

let interactions;
let gas;
let (input, mut output);

[squadgazzz]

This function can go away then.

[MartinquaXD]

Just a first look. I'll try to do another deeper review later.

[MartinquaXD]

I would like to get some feedback from solvers how they would expect this to work. Specifically to ask them about using the regular quoting logic vs. building something into the orderbook which only needs the native price of the tokens and a simulation to get the gas amount.

[MartinquaXD]

This change is not needed anymore, right?

[m-sz]

When the whole E2E test suite is run, the test onchain_settlement_without_liquidity from buffers.rs seems to hit this, probably due to the change in quote verification?

[MartinquaXD]

We can simply use order.buy.token, no?

[m-sz]

I think it ought to be the sell token, as per the comments.

[MartinquaXD]

Probably nicer to make this an early return.

[squadgazzz]

@m-sz please also update https://github.com/gnosis/solvers, so none of the solvers waste the third-party API requests on sending orders that can't be solved. So each solver needs to filter out such orders in advance.

[MartinquaXD]

Since we probably need to have an if here anyway we can probably also leave the routing logic completely untouched (i.e. revert changes for allowing empty route segments). Rather than having the if after calling route() here we could instead have the if sell == buy and only call route() in the other case, right?

[m-sz]

That's correct. I am fine with making this change