Change on-chain router to select lowest slippage route

Our on-chain router stores a route between two assets that is independent of trade size. This makes comparison of execution price not ideal, because choice of route by execution price will vary depending on the trade size.

Instead, I would propose the on-chain router store the route with lowest aggregate slippage.

The router will have to calculate the aggregate slippage of two routes (the currently stored route and the new proposed route) and select the route with the lowest aggregate slippage.
For example, suppose the routes from token A to B are
A -> C -> D -> B, and
A -> E -> B.
The router validation first must make a reasonable selection for trade size (for example, minimum of 1% of the A pools of each of the two routes). Then validation logic computes the A -> C trade slippage S1 with this trade size, as well as the amount_out in asset C. This amount_out is then used in the C -> D calculation, to calculate the slippage S2 of the C -> D trade.
The slippages S1, S2, S3, ... are calculated for every hop along the route, and then aggregated.
There are multiple ways to aggregate, one such way could be S_aggregate = (1 + S1) * (1 + S2) * (1 + S3) * ...
A similar calculation is done for the second route, and the route with the lowest aggregate slippage is set as the on-chain route.

Potential issue to keep in mind:
Suppose there are two routes from A -> B
A -> C -> D -> B going through C/D pool 1, and
A -> C -> D -> B going through C/D pool 2.
Suppose C/D pool 2 has a "wrong" price, i.e. different from the external market, while C/D pool 1 has the correct (market) price.
Suppose the A/C and D/B pools in the routes are the same. Suppose also that C/D pool 2 is less liquid (more slippage) than C/D pool 1.

The first route calculation would be as intended. The second route calculation would have correct slippage values for the A -> C and C -> D trades. However the "wrong" C/D price in pool 2 could result in much less of token D being used in the D -> B slippage calculation. Smaller D trade would result in lower slippage for route 2 than route 1 in the D -> B pool. However note that this lower slippage is precisely because the 2nd route is worse for the trader.

Possible solution: The approach above uses sells to calculate slippage. This creates the situation where a route that is worse for the trader has lower slippage. If buys are used instead, we still have the problem where the route selected could have lower liquidity, but it would be due to price differences in favor of the trader.

No files, tests, or specific entry points are named. Start by locating the on-chain router and its route-validation logic, then clarify the trade-size and aggregate-slippage design before implementation; done means route selection consistently chooses the intended lowest-slippage route and covers the contrasting-price scenario described here.

Written by the indexing model from the issue text.