[CL][Swap Router Module]: investigate reducing the need for making public swap API with swapFee as parameter

[p0mvn]

Background

In #3128 we refactored gamm to lift multihop logic up to swap-router. This has led to
exporting a gamm and concentrated-liquidity swap APIs that take swap fee as parameter.

This poses a security risk since a developer might accidentally provide a fee that is lower than the actual pool fee.

Ultimately, the only reason for exposing swap fee in the API is so that we can reduce the fee for osmo routed mutlihop:

osmosis/x/swaprouter/router.go

Lines 27 to 29 in 1f9680c

	swapFeeMultiplier = gammtypes.MultihopSwapFeeMultiplierForOsmoPools.Clone()
	}

Suggested Design

We should investigate potential approaches to mitigate this security vulnerability and come up with an abstraction that does not expose swapFee publicly.

Acceptance Criteria

• refactor to avoid exposing swapFee in SwapExactAmountIn globally
• refactor to avoid exposing swapFee in SwapExactAmountOut globally
• refactor tests
• add new if applicable

[mattverse]

@p0mvn Regarding this issue, it seems inevitable to completely remove swapFee related argument since we're handling multihop logic in the pool model layer. It seems that there are two possible ways to tackle this

1. move multihop related logic to each pool module layer
2. refactor so that we don't pass in the swapFee itself but change the swap Fee into a boolean argument names isMultihopRouted and then calculate the actual swap fee within each pool module's swap methods.

Although option 2 does not completely solve the problem this issue is particularly mentioning, it does reduce the security risk introduced in this issue. What are your thoughts?

[mattverse]

Decision made to take option2 above. If code duplication seems unnecessarily excessive, dropping this issue since it would not make sense to make the trade off of massive code duplication vs minor API vulnerability

[mattverse]

Blocked on investigation on how multihop fees are being charged right now

[mattverse]

After some investigation, I came to the conclusion of having to leave swapFees as is.

Currently we're taking the multihop swap fees via max of individual swap fees and the average swap fees of the swaps). This means that we always need to calculate the swap fees at the highest level that multihop takes place and then provide them via parameters. This lead to the conclusion that our current API stands valid, open to any other ideas or suggestions