build: limit modules

[Schlagonia]

Description

• add a default max_withdraw function that simulates a actual withdraw to make sure the maxWithdraw and maxRedeem functions comply to the 4626 standard.
• add the option to add deposit and withdraw modules for custom deposit and withdraw limits.

Fixes # (issue)

Checklist

• I have run vyper and solidity linting
• I have run the tests on my machine
• I have followed commitlint guidelines
• I have rebased my changes to the latest version of the main branch

[jmonteer]

1. I have a concern about a vault manager using both deposit_limit and deposit_limit_module and not have the expected output. (i.e. set deposit_limit to 0 while deposit_limit_module returns a different value can lead to the manager to think nobody can deposit, but that not being true). A potential solution could be to require deposit_limit to be uint256.max to set deposit_limit_module, and deposit_limit_module to be set to empty(address) if you want to set deposit_limit. Does that make sense?

2. The only think I don't like about deposit_limit_module and withdraw_limit_module is that it adds gas to the most basic functions (deposit and redeem). but I like freedom of set up

[Schlagonia]

1. I have a concern about a vault manager using both deposit_limit and deposit_limit_module and not have the expected output. (i.e. set deposit_limit to 0 while deposit_limit_module returns a different value can lead to the manager to think nobody can deposit, but that not being true). A potential solution could be to require deposit_limit to be uint256.max to set deposit_limit_module, and deposit_limit_module to be set to empty(address) if you want to set deposit_limit. Does that make sense?

This is a good point. Added asserts to both setters to make sure both arent used at once 5cc8b5f

2. The only think I don't like about deposit_limit_module and withdraw_limit_module is that it adds gas to the most basic functions (deposit and redeem). but I like freedom of set up

Yes, its not ideal. However the withdraw_limit_module could actually be cheaper due to the need to iterate over a queue in order to get a correct amount with the new version.

[fp-crypto]

Should we also special case 0?

[Schlagonia]

Well people shouldnt be sending 0 in any of the external functions as an input.

But there is the case that the report event calls convert_to_assets twice with a 0 value if no fees are charged. So it would save gas there

[Schlagonia]

added ecf23db

[fp-crypto]

LGTM, but i did have 1 minor comment #179 (comment)