fix: prevent borrowing limit violation during facade migration

[lekhovitsky]

Fixes https://github.com/spearbit-audits/review-gearbox/issues/58

[StErMi]

The implementation achieves to solve the issue described in https://github.com/spearbit-audits/review-gearbox/issues/58 but brings some drawbacks in the process: now every time that the CreditFacadeV3.setDebtLimits is executed the totalBorrowedInBlock state variable is initialized to type(uint128).max.

This means that every time that the CreditConfiguratorV3 calls one of the following functions:

• setCreditFacade with migrateParams == true
• setMaxDebtPerBlockMultiplier
• forbidBorrowing (this can be excluded because the intent is to indeed forbid borrowing)
• setMinDebtLimit
• setMaxDebtLimit

and maxDebtPerBlockMultiplier is not configured to be equal to type(uint8).max (skip the borrowing per block check), any borrowing operations included in the block will revert.

@lekhovitsky and Gearbox team, could you please confirm that this is the behavior you want to achieve with this PR?

[lekhovitsky]

@StErMi yeah that's fine, since we're restricting the system anyways it doesn't hurt much to revert during some risky actions (which borrowing is) performed right after configuration, especially given that (i) the only loss is gas fees paid (ii) the likelihood of this actually happening is quite low and (iii) alternative solutions to the problem were really cumbersome.

On Ethereum Mainnet (the only place where gas fees for reverts can be considerable), there are some additional practical considerations on why this won't likely be an issue:

• typically, borrowing operations are coupled with swaps of various kinds which entail MEV, so block builders would be incentivized to place them before our configuration transactions within a single block;
• RPC endpoints that guarantee non-inclusion of reverting txs are quite common nowadays.