Bequest Finance

The order of external call/transfer and storage manipulation must follow the check-effect-interaction pattern.[LINK](https://fravoll.github.io/solidity-patterns/checks_effects_interactions.html)

Distribution fee may be bypassed by bequester. Function `distribute()` uses `safeSendERC20s()` to collect the distribution fees. Function safeSendERC20s() has the issue reflected in BWV-03, that the bequester could change the allowance to the `BequestWillV1` contract after the bequest becomes claimable. If the bequester set the allowance to 0 before the first `distribution()` call, he won't pay any distribution fees, and the first recipients won't receive any tokens. The bequester can then set the allowance back to normal to allow the normal bequest process. On the other hand, if the bequester is still able to reset the allowance after the bequest is claimable, he could simply transfer out the token without the bequest service.

The contract is serving as the underlying entity to interact with third party ERC20, ERC721 and ERC1155 at the bequest owners' choice. The scope of the audit treats 3rd party entities as black boxes and assume their functional correctness. However, in the real world, 3rd parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of 3rd parties can possibly create severe impacts, such as increasing fees of 3rd parties, migrating to new LP pools, etc.