[asset-swapper] clip native fill data

[dekz]

Description

There is a scenario where perfectly sized Native orders were penalized more aggressively than they should have been.

The previous behaviour was as follows:

penaltyMakerUnits = 10
input = 2000

SMALL_ORDER
makerAmount = 100
takerAmount = 200

adjustedOutput = 90
adjustedRate = 0.45


BIG_ORDER
makerAmount = 1000
takerAmount = 2000

adjustedOutput = 990
adjustedRate = 0.495

In the scenario where the user wishes to sell 2000 the SMALL_ORDER should be penalized over BIG_ORDER and BIG_ORDER should be favoured.

In the scenario where the user wishes to sell 200 both SMALL_ORDER and BIG_ORDER are sufficient and either is acceptable to fill.

penaltyMakerUnits = 10
input = 200

SMALL_ORDER
makerAmount = 100
takerAmount = 200

adjustedOutput = (min(takerAmount, input) / takerAmount) * makerAmount - penaltyMakerUnits = 90
adjustedRate = 0.45


BIG_ORDER
makerAmount = 1000
takerAmount = 2000

adjustedOutput = (min(takerAmount, input) / takerAmount) * makerAmount - penaltyMakerUnits = 90
adjustedRate = 0.45

We effectively bring large orders in line with small orders when they completely cover the requested amount.

Issue

The following behaviour caused perfectly sized orders to disappear:

1. Perfectly sized orders were penalized more harshly than large orders
2. Native orders are sorted by adjustedRate, then a subset of native orders are chosen (enough to fill the requested amount).
3. Since better rate orders were dropped in 2), they would no longer be present when finding a path.

[coveralls]

Coverage increased (+0.08%) to 79.563% when pulling bf626a0 on fix/asset-swapper-native-adjusted-output into 501070b on development.

[PirosB3]

I really appreciate your swift PR

[PirosB3]

should not be penalized the same?

[dekz]

they should be penalized the same, since the cost is constant and the amount is constant. Where having a bigger order size is no advantage.

[PirosB3]

should we be concerned about rounding errors with this operation? of does BigNumber prevent rounding issues?

[dekz]

These remain very precise, but I could go either way in having these as whole base units which would lose precision but not necessarily have too much of an impact.

[PirosB3]

Why was this function modified? based on my understanding, it should not impact nativeOrdersToPath which is the core function that you changed

[dekz]

I find it just easier to reason about. input * rate = output, versus scaling the previous output by the proportion of remaining vs total.