Vulnerability: Exponential and logarithmic price adapters will return incorrect pricing when moving from higher dp token to lower dp token
Severity: medium

Description:
The exponential and logarithmic price adapters do not work correctly when used with token pricing of different decimal places. This is because the resolution of the underlying expWad and lnWad functions is not fit for tokens that aren't 18 dp.\\nAuctionRebalanceModuleV1.sol#L856-L858\\n```\\nfunction _calculateQuoteAssetQuantity(bool isSellAuction, uint256 _componentQuantity, uint256 _componentPrice) private pure returns (uint256) {\\n    return isSellAuction ? _componentQuantity.preciseMulCeil(_componentPrice) : _componentQuantity.preciseMul(_componentPrice);\\n}\\n```\\n\\nThe price returned by the adapter is used directly to call _calculateQuoteAssetQuantity which uses preciseMul/preciseMulCeil to convert from component amount to quote amount. Assume we wish to sell 1 WETH for 2,000 USDT. WETH is 18dp while USDT is 6dp giving us the following price:\\n```\\n1e18 * price / 1e18 = 2000e6\\n```\\n\\nSolving for price gives:\\n```\\nprice = 2000e6\\n```\\n\\nThis establishes that the price must be scaled to:\\n```\\nprice dp = 18 - component dp + quote dp\\n```\\n\\nPlugging in our values we see that our scaling of 6 dp makes sense.\\nBoundedStepwiseExponentialPriceAdapter.sol#L67-L80\\n```\\n    uint256 expExpression = uint256(FixedPointMathLib.expWad(expArgument));\\n\\n    // Protect against priceChange overflow\\n    if (scalingFactor > type(uint256).max / expExpression) {\\n        return _getBoundaryPrice(isDecreasing, maxPrice, minPrice);\\n    }\\n    uint256 priceChange = scalingFactor * expExpression - WAD;\\n\\n    if (isDecreasing) {\\n        // Protect against price underflow\\n        if (priceChange > initialPrice) {\\n            return minPrice;\\n        }\\n        return FixedPointMathLib.max(initialPrice - priceChange , minPrice);\\n```\\n\\nGiven the pricing code and notably the simple scalingFactor it also means that priceChange must be in the same order of magnitude as the price which in this case is 6 dp. The issue is that on such small scales, both lnWad and expWad do not behave as expected and instead yield a linear behavior. This is problematic as the curve will produce unexpected behaviors under these circumstances selling the tokens at the wrong price. Since both functions are written in assembly it is very difficult to determine exactly what is going on or why this occurs but testing in remix gives the following values:\\n```\\nexpWad(1e6) - WAD = 1e6\\nexpWad(5e6) - WAD = 5e6\\nexpWad(10e6) - WAD = 10e6\\nexpWad(1000e6) - WAD = 1000e6\\n```\\n\\nAs seen above these value create a perfect linear scaling and don't exhibit any exponential qualities. Given the range of this linearity it means that these adapters can never work when selling from higher to lower dp tokens.

Impact:
Exponential and logarithmic pricing is wrong when tokens have mismatched dp

Recommended mitigation:
scalingFactor should be scaled to 18 dp then applied via preciseMul instead of simple multiplication. This allows lnWad and expWad to execute in 18 dp then be scaled down to the correct dp.