Upgrade BeefyVaults to allow EIP-2612 signed approvals

[PandaWhisperer]

I noticed a few DApps now make use of a new spending permission system outlined in EIP-2612, which involves signing a message in your wallet instead of a separate approval transaction (more details here: https://soliditydeveloper.com/erc20-permit).

Obviously, the token being spent must support this approval style, namely, it must implement the following three methods:

function permit(address owner, address spender, uint value, uint deadline, uint8 v, bytes32 r, bytes32 s) external
function nonces(address owner) external view returns (uint)
function DOMAIN_SEPARATOR() external view returns (bytes32)

It does appear that at least SpiritSwap LP tokens on Fantom DO implement this approval style (for example, the USDC-fUSDT pair. Not sure if this only goes for newer pairs and what other exchanges have implemented this, but I will do some research and add a list here.

Of course, the app would need some updates as well in order to support this approval style (and autodetect when it is available), but more importantly, the vaults would need to support this first. I found a possible implementation on a YieldYak vault (license is MIT):

 /**
     * @notice Deposit using Permit
     * @param amount Amount of tokens to deposit
     * @param deadline The time at which to expire the signature
     * @param v The recovery byte of the signature
     * @param r Half of the ECDSA signature pair
     * @param s Half of the ECDSA signature pair
     */
    function depositWithPermit(
        uint256 amount,
        uint256 deadline,
        uint8 v,
        bytes32 r,
        bytes32 s
    ) external override {
        depositToken.permit(msg.sender, address(this), amount, deadline, v, r, s);
        _deposit(msg.sender, amount);
    }

A potential depositAllWithPermit() function would look similar.

In the app, the following steps would be required:

1. Detect if deposit token (i.e. want) supports EIP-2612 approvals.
2. Produce permission message and ask user to sign it
3. Instead of calling deposit(amount) or depositAll(), call the _WithPermit version, using the appropriate parameters.

While I don't think this saves any gas or transaction fees (after all, the permit() function still calls approve(), and must additionally decode the signed message), it is a nice quality-of-life improvement and does improve security, since no permanent approvals are required.

Would it be possible to include this in the next iteration of the vault contract?