Hexens Audit: ConvexStFrxEthStrategy: Follow Up

SPOOL2-2 - `DISCREPANCIES IN _REDEEMFROMPROTOCOL FUNCTION IMPLEMENTATION`

Commit: https://github.com/SpoolFi/spool-v2-core/commit/86065428a4d5e6de3c7b10909db532033c578c80
Description:
- Acknowledged, implemented in the commit hash above.
- the _redeemFromProtocol() function now uses just one slippage value, for the output WETH amount. We pass an empty array to redeem inner for the slippages, as we assume that we will catch any issues on the output WETH amount. We must allow passing slippages to _redeemInner, as in the emergencyWithdraw function, we will just get back stETH and frxETH and send to the emergency recipient, and so we still want to use slippages for stETH and frxETH in this case. I've updated the redeemFast/emergencyWithdraw description, to better relate this.
- In this commit, I have also included some event emissions that we missed:
  - in assetGroupWrap, we return a ratio array, which represents the amounts of stETH/frxETH that's used as input to the correspending wrap functions. these are then emitted in depositToProtocol, if this call is a view execution.
  - in _compound, we emit the LP amount received, if this call is a view execution.

Commit: N/A
Description:
- On review of this issue, we have decided to not implement a change. The assumption that frxETH and stETH have equivalent value (or close to) to WETH is a strong enough assumption for the functioning of the protocol. Any significant deviation has a very low probability of occuring.
- The other technical aspect of why we cannot change this is to do with the architecture of the doHardWork: WETH is the asset group of this strategy, and the way it is architected is that we can only pass the exchange rate for the asset group tokens to getUsdWorth. As a result we can only pass the WETH price, without significantly modifying core code. This is how we implement strategies SfrxEthHoldingStrategy and StEthHoldingStrategy; WETH is always the exchange rate used, as the asset group token is WETH.

Commit: N/A
Description:
- On review of this issue, we have decided not to implement a change. While we don't explicitly check the result of lido.submit, the output value from this call is fed into add_liquidity, which we do check slippage on.
- This pattern is repeated in the redeem flow, where we only check the output weth amount. Given this, we think that sufficient slippage is already in place.