eMode implementation is completely broken
Enabling eMode allows assets of the same class to be borrowed at much higher a much higher LTV. The issue is that the current implementation makes the incorrect calls to the Aave V3 pool making so that the pool can never take advantage of this higher LTV.\\nAaveLeverageStrategyExtension.sol#L1095-L1109\\n```\\nfunction _calculateMaxBorrowCollateral(ActionInfo memory _actionInfo, bool _isLever) internal view returns(uint256) {\\n    \\n    // Retrieve collateral factor and liquidation threshold for the collateral asset in precise units (1e16 = 1%)\\n    ( , uint256 maxLtvRaw, uint256 liquidationThresholdRaw, , , , , , ,) = strategy.aaveProtocolDataProvider.getReserveConfigurationData(address(strategy.collateralAsset));\\n\\n    // Normalize LTV and liquidation threshold to precise units. LTV is measured in 4 decimals in Aave which is why we must multiply by 1e14\\n    // for example ETH has an LTV value of 8000 which represents 80%\\n    if (_isLever) {\\n        uint256 netBorrowLimit = _actionInfo.collateralValue\\n            .preciseMul(maxLtvRaw.mul(10 ** 14))\\n            .preciseMul(PreciseUnitMath.preciseUnit().sub(execution.unutilizedLeveragePercentage));\\n\\n        return netBorrowLimit\\n            .sub(_actionInfo.borrowValue)\\n            .preciseDiv(_actionInfo.collateralPrice);\\n```\\n\\nWhen calculating the max borrow/repay allowed, the contract uses the getReserveConfigurationData subcall to the pool.\\nAaveProtocolDataProvider.sol#L77-L100\\n```\\nfunction getReserveConfigurationData(\\n  address asset\\n)\\n  external\\n  view\\n  override\\n  returns (\\n      // rest of code\\n  )\\n{\\n  DataTypes.ReserveConfigurationMap memory configuration = IPool(ADDRESSES_PROVIDER.getPool())\\n    .getConfiguration(asset);\\n\\n  (ltv, liquidationThreshold, liquidationBonus, decimals, reserveFactor, ) = configuration\\n    .getParams();\\n```\\n\\nThe issue with using getReserveConfigurationData is that it always returns the default settings of the pool. It never returns the adjusted eMode settings. This means that no matter the eMode status of the set token, it will never be able to borrow to that limit due to calling the incorrect function.\\nIt is also worth considering that the set token as well as other integrated modules configurations/settings would assume this higher LTV. Due to this mismatch, the set token would almost guaranteed be misconfigured which would lead to highly dangerous/erratic behavior from both the set and it's integrated modules. Due to this I believe that a high severity is appropriate.
Pull the adjusted eMode settings rather than the base pool settings
Usage of eMode, a core function of the contracts, is completely unusable causing erratic/dangerous behavior
```\\nfunction _calculateMaxBorrowCollateral(ActionInfo memory _actionInfo, bool _isLever) internal view returns(uint256) {\\n    \\n    // Retrieve collateral factor and liquidation threshold for the collateral asset in precise units (1e16 = 1%)\\n    ( , uint256 maxLtvRaw, uint256 liquidationThresholdRaw, , , , , , ,) = strategy.aaveProtocolDataProvider.getReserveConfigurationData(address(strategy.collateralAsset));\\n\\n    // Normalize LTV and liquidation threshold to precise units. LTV is measured in 4 decimals in Aave which is why we must multiply by 1e14\\n    // for example ETH has an LTV value of 8000 which represents 80%\\n    if (_isLever) {\\n        uint256 netBorrowLimit = _actionInfo.collateralValue\\n            .preciseMul(maxLtvRaw.mul(10 ** 14))\\n            .preciseMul(PreciseUnitMath.preciseUnit().sub(execution.unutilizedLeveragePercentage));\\n\\n        return netBorrowLimit\\n            .sub(_actionInfo.borrowValue)\\n            .preciseDiv(_actionInfo.collateralPrice);\\n```\\n