Fixes #730. accruedToTreasury not being properly considered together with aToken supply

[eboadom]

#730

The changes included in this PR are the following:

• On both FlashLoan and BridgeLogic the accumulation to the liquidity index now includes both aToken supply and scaled-up accruedToTreasury.
• On ValidationLogic, now validateSupply() takes into account accruedToTreasury, to not allow deposits when (aToken supply + scaled-up accruedToTreasury) is bigger than the supply cap.
• Also on ValidationLogic, validateDropReserve now checks that both aToken supply and accruedToTreasury are 0.
• On PoolConfigurator, _checkNoSuppliers() checks that accruedToTreasury is 0, as factually the Collector is a depositor in that case, even if not holding aToken.
• Tests for the most important fix, affecting flash loan fee (and bridge fee, but it is exactly the same)
• Test for fixes on validations

[miguelmtzinf]

I guess adding up the scaled amounts and multiplying will be the same and save 1 operation. Is there a reason you didn't do it?

[eboadom]

You are right, makes more sense. Will change

[miguelmtzinf]

LGTM. Looking forward to the validation tests

[miguelmtzinf]

I'm in doubt about if the aToken should also reflects this in its totalSupply() and scaledTotalSupply() functions.

Three issues:

1. The aToken real totalSupply should account for accruedToTreasury, becuase its actually part of the aToken supply (just a deferred mint)
2. The AaveIncentivesController handleAction() call is wrong, because we are passing a smaller value: https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/tokenization/base/IncentivizedERC20.sol#L206
3. Integrations can become cumbersome if they use the aToken totalSupply without taking the consideration of accounting the accruedToTreasury. This is the case of the Rewards contracts (similar to 2):
   https://github.com/aave/aave-v3-periphery/blob/master/contracts/rewards/RewardsController.sol#L85
   https://github.com/aave/aave-v3-periphery/blob/master/contracts/rewards/RewardsDistributor.sol#L189

[eboadom]

I'm in doubt about if the aToken should also reflects this in its totalSupply() and scaledTotalSupply() functions.

Three issues:

1. The aToken real totalSupply should account for accruedToTreasury, becuase its actually part of the aToken supply (just a deferred mint)
2. The AaveIncentivesController handleAction() call is wrong, because we are passing a smaller value: https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/tokenization/base/IncentivizedERC20.sol#L206
3. Integrations can become cumbersome if they use the aToken totalSupply without taking the consideration of accounting the accruedToTreasury. This is the case of the Rewards contracts (similar to 2):
   https://github.com/aave/aave-v3-periphery/blob/master/contracts/rewards/RewardsController.sol#L85
   https://github.com/aave/aave-v3-periphery/blob/master/contracts/rewards/RewardsDistributor.sol#L189

1. I thought about it, but don't agree. The aToken supply should only represent the total supply of minted tokens. Withdrawal rights are then managed by the pool, so the token should not really be aware of the accruedToTreasury
2. It is fine, just that the accruedToTreasury will start to accrue rewards whenever minted. I think it is legit, if not, will break 1).
3. It is not really a problem. It is way worse for integrators if there is some extra component to form the total of scaledTotalSupply()

[miguelmtzinf]

I'm in doubt about if the aToken should also reflects this in its totalSupply() and scaledTotalSupply() functions.
Three issues:

1. The aToken real totalSupply should account for accruedToTreasury, becuase its actually part of the aToken supply (just a deferred mint)
2. The AaveIncentivesController handleAction() call is wrong, because we are passing a smaller value: https://github.com/aave/aave-v3-core/blob/master/contracts/protocol/tokenization/base/IncentivizedERC20.sol#L206
3. Integrations can become cumbersome if they use the aToken totalSupply without taking the consideration of accounting the accruedToTreasury. This is the case of the Rewards contracts (similar to 2):
   https://github.com/aave/aave-v3-periphery/blob/master/contracts/rewards/RewardsController.sol#L85
   https://github.com/aave/aave-v3-periphery/blob/master/contracts/rewards/RewardsDistributor.sol#L189

1. I thought about it, but don't agree. The aToken supply should only represent the total supply of minted tokens. Withdrawal rights are then managed by the pool, so the token should not really be aware of the accruedToTreasury
2. It is fine, just that the accruedToTreasury will start to accrue rewards whenever minted. I think it is legit, if not, will break 1).
3. It is not really a problem. It is way worse for integrators if there is some extra component to form the total of scaledTotalSupply()

Fair enough. Although debatable, this is probably the approach that makes most sense. Thanks