Added endpoints with default values

[Rubilmax]

Pull Request

Keep in mind that doing so has an advantage and an inconvenient (I do support the change):

• Etherscan and the contract itself will expose a broader API with default values
• ethers.js and all off-chain integrations will require to interact with the vault by specifying the type of function they want to interact with (and not its name only; e.g. deposit(uint256,address) instead of deposit)

The latter is of no importance to me, as the integrator that I may be

[MerlinEgalite]

Changes LGTM but want to hear the thoughts of others before we merge this PR

[QGarchery]

LGTM

[QGarchery]

Maybe add underscore before the arguments of the functions

[Rubilmax]

It's not the convention used this implementation, as it inherits OZ's conventions... So I don't think it's welcomed here

[QGarchery]

Ok np, it's just that there is one in the functions above

[MerlinEgalite]

To update

[MathisGD]

I think that it should be tested quickly.

[MerlinEgalite]

I'm not sure it's worth it. These functions will only be used by our frontend as every other protocol will use the ERC-4626 interface (else why bother with a standard?). This PR also increases the attack surface and the likelihood to make mistakes later in the future. What do you think @morpho-dao/solidity ?

[Rubilmax]

This PR also increases the attack surface

Adding external functions is not enough to increase the attack surface: here for example, we add external functions without adding features; we're only constraining the usage of the more generic entrypoint to a safe scenario - from the point of view of any caller (background focus being that when calling such a function, a caller always has access to their funds afterwards)

Otherwise, I agree with the other point

I support this change as an integrator (on & off-chain, it's just easier and trustless to call deposit(1 ether))

[Rubilmax]

Dropping this