Gas optimizations by reorganizing the `PoolStorage` layout

[The-3D]

Identified by: Aave team

Scope:

In the storage layout of the PoolStorage contract, various optimizations are possible:

1. _reservesCount does not need to be uint256; can be a uint16 and paired with the _addressesProvider and the _maxBorrowStableRatePercent (which can also be reduced to a uint64) to save two SLOAD in borrow and flashloan and one SLOAD in withdraw, liquidationCall

2. _flashloanPremiumTotal and _flashloanPremiumToProtocol can be reduced to uint128 to save one SLOAD in flashloan, flashloanSimple

[LHerskind]

• Should probably build on the fix from #196.
• Why uint16 for _reservesCount? it should only hold up to 128, so uint8 could be used, giving more room for _maxBorrowStableRatePercent
• _maxNumberOfReserves need not be uint256 when the _reservesCount is smaller. If both _maxNumberOfReserves and _reservesCount is uint8, they could be in the same slot as well.

[The-3D]

i left uint16 for _reservesCount to leave more margin - we can potentially extend the reserve configuration infinitely by adding more uints in the future. uint16 allows for 16536 max reserves without much impact on the storage size furthermore _maxBorrowStableRatePercent is a percentage with 2 decimal precision so it can't be bigger than 10000

Regarding _maxNumberOfReserves, this should be handled differently - this storage variable is not needed at all. I opened another issue on this https://github.com/aave/aave-v3-core/issues/237

[LHerskind]

The _addressesProvider is only set once in the initialize, is there a reason that we are not using an immutable here instead? The only reason I can think of is from V2 to reuse the implementation across different markets

[The-3D]

We can make the _addressesProvider immutable. Please open another issue for that