USD0 Updates

In the run function the reward tokens are transferred to the router address instead of approving the router address and allowing the router to transferFrom the harvester contract. The Odos router is planned to be used, based upon deploy scripts, and attempts to transferFrom the caller instead of relying on the router contract balance, thus any funds sent to the Odos router would be trapped. As long as a nonzero amountOut is specified and the asset balance of the harvester is zero then this swap will simply fail rendering the harvester incapable of performing harvest actions.

Include optionality for whether to transfer funds to the router address or to approve the router address in the run function.

The Harvester run function calls distribute rewards on the MagicUSD0pp vault which immediately increases the value of the MagicUsd0++ shares. Given the vault exists on ethereum mainnet this value increase may be arbitraged by an actor observing the mempool for a large harvest. The attacker may deposit directly before and withdraw directly after the share value increase for risk free gain.

Consider introducing a deposit/withdrawal fee to ensure that a reasonable sized harvest cannot be profitably arbitraged. Otherwise consider adding logic such that the harvested rewards are distributed to the vault over time to avoid stepwise jumps in share value.

In the setAllowedRouter and setFeeParameters functions events are emitted indicating that a configuration change has taken place even when the configurations have not changed.

Be aware of this behavior and consider reverting/not emitting these events when the new configurations are the same as the existing configurations.

In MagicUsd0pp.s.sol script the ownership of the vault is transferred to the safe.ops toolkit address, however the ownership for the harvester contract is left with the EOA executing the script.

Consider transferring the harvester ownership to the safe.ops address in the toolkit at the end of the deploy script.