Vulnerability: WIchiFarm will break after second deposit of LP
Severity: medium

Description:
WIchiFarm.sol makes the incorrect assumption that IchiVaultLP doesn't reduce allowance when using the transferFrom if allowance is set to type(uint256).max. Looking at a currently deployed IchiVault this assumption is not true. On the second deposit for the LP token, the call will always revert at the safe approve call.\\nIchiVault\\n```\\n  function transferFrom(address sender, address recipient, uint256 amount) public virtual override returns (bool) {\\n      _transfer(sender, recipient, amount);\\n      _approve(sender, _msgSender(), _allowances[sender][_msgSender()].sub(amount, "ERC20: transfer amount exceeds allowance"));\\n      return true;\\n  }\\n```\\n\\nThe above lines show the trasnferFrom call which reduces the allowance of the spender regardless of whether the spender is approved for type(uint256).max or not.\\n```\\n    if (\\n        IERC20Upgradeable(lpToken).allowance(\\n            address(this),\\n            address(ichiFarm)\\n        ) != type(uint256).max\\n    ) {\\n        // We only need to do this once per pool, as LP token's allowance won't decrease if it's -1.\\n        IERC20Upgradeable(lpToken).safeApprove(\\n            address(ichiFarm),\\n            type(uint256).max\\n        );\\n    }\\n```\\n\\nAs a result after the first deposit the allowance will be less than type(uint256).max. When there is a second deposit, the reduced allowance will trigger a safeApprove call.\\n```\\nfunction safeApprove(\\n    IERC20Upgradeable token,\\n    address spender,\\n    uint256 value\\n) internal {\\n    // safeApprove should only be called when setting an initial allowance,\\n    // or when resetting it to zero. To increase and decrease it, use\\n    // 'safeIncreaseAllowance' and 'safeDecreaseAllowance'\\n    require(\\n        (value == 0) || (token.allowance(address(this), spender) == 0),\\n        "SafeERC20: approve from non-zero to non-zero allowance"\\n    );\\n    _callOptionalReturn(token, abi.encodeWithSelector(token.approve.selector, spender, value));\\n}\\n```\\n\\nsafeApprove requires that either the input is zero or the current allowance is zero. Since neither is true the call will revert. The result of this is that WIchiFarm is effectively broken after the first deposit.

Impact:
WIchiFarm is broken and won't be able to process deposits after the first.

Recommended mitigation:
Only approve is current allowance isn't enough for call. Optionally add zero approval before the approve. Realistically it's impossible to use the entire type(uint256).max, but to cover edge cases you may want to add it.\\n```\\n    if (\\n        IERC20Upgradeable(lpToken).allowance(\\n            address(this),\\n            address(ichiFarm)\\n-       ) != type(uint256).max\\n+       ) < amount\\n    ) {\\n\\n+       IERC20Upgradeable(lpToken).safeApprove(\\n+           address(ichiFarm),\\n+           0\\n        );\\n        // We only need to do this once per pool, as LP token's allowance won't decrease if it's -1.\\n        IERC20Upgradeable(lpToken).safeApprove(\\n            address(ichiFarm),\\n            type(uint256).max\\n        );\\n    }\\n```\\n