bug(low-severity): fee calculation on GeometricMean

[Autoparallel]

Description

The GeometricMean strategy uses an incorrect fee calculation for the increase in L that is off by a factor of 2.

Details

The fee calculation roughly looks like

fees = amountIn * swapFee;
deltaL = fees * L / R

where R is either one of the two reserves, and specifically is the reserve that is being tendered in for a swap.

Replication of the issue

To see why this is off, take a pool with a swap fee of 0.003, initial price of 1, initial X of 10E9, and then perform a swap of 1 of X or Y in. This liquidity depth and swap size should make it such that the pool is close to being a ConstantSum pool. What you find is that instead of getting out 0.997 of the other token, you get back 0.994 indicating the fee was double counted.

Fix

To fix the issue, simply divide the above deltaL by 2.

Testing in Mathematica notebooks seems to show this change fixes the fee problem.

[0xJepsen]

Do we want to document these bugs in the report actually?

[Autoparallel]

Do we want to document these bugs in the report actually?

This wasn't found with arbiter, just fyi