Rate-limit Dex solver solver requests

[fleupold]

The Dex solver (1Inch, Paraswap, 0x) is implemented in a way that it attempts to find a solution to each order in the batch individually (default batch size is 1)

services/crates/solvers/src/domain/solver/dex/mod.rs

Lines 73 to 87 in 148a922

	fn solution_stream<'a>(
	&'a self,
	auction: &'a auction::Auction,
	) -> impl stream::Stream<Item = solution::Solution> + 'a {
	stream::iter(auction.orders.iter().filter_map(order::UserOrder::new))
	.enumerate()
	.map(|(i, order)| {
	let span = tracing::info_span!("solve", order = %order.get().uid);
	self.solve_order(order, &auction.tokens, auction.gas_price)
	.map(move |solution| solution.map(|s| s.with_id(solution::Id(i as u64))))
	.instrument(span)
	})
	.buffer_unordered(self.concurrent_requests.get())
	.filter_map(future::ready)
	}

However, it does not respect or feed-back if the API returns rate-limit errors, which can be seen in the logs here.

In this case, instead of continuing to hammer the API with requests (and causing other consumers to have less API capacity), it should back off and try again after a cool down period.

Suggested Chages

• Add a new RateLimited variant on solvers::infra::dex::Error
• Parse each individual dex solver's HTTP sub-error with status 429 into this error type
• use something like shared::rate_limiter::RateLimiter inside domain::solver::dex when solving the single orders

Given that the new infra should not directly depend on the shared crate, we can either reimplement the rate_limiter logic or pass it through a boundary struct (similar to how e.g. the boundary::baseline has access to the shared::baseline_solver)