Not compound rate variation ?

[MathisGD]

          I seriously wonder if it is not a bit overkill. This computation cost a non-negligible amount of gas, and it is complex: it requires to ensure that there are no overflow in a computation up to a power of 12 (and it has also a limit when the linear variation is < -3).

Something simpler like

        uint256 variationMultiplier = WAD_INT + linearVariation;

would not have those issues. I understand that we would lose the property that having multiple updates in an interval is the same as having one update at the end, but this is only a third order loss in the worst case:

• approximating an amount is a first order precision issue
• approximating the rate (for example linear instead of compounded) is a second order precision issue
• approximating the variation of the rate is a third order precision issue

It was already unclear for rates if it was worth the extra computation cost, it may be the case here that it's not worth at all

_Originally posted by @QGarchery in https://github.com/morpho-labs/morpho-blue-periphery/pull/1#discussion_r1311530246_

[MathisGD]

I think that the benefit of this is small now that we have #12