feat(interests): make accrueInterests public

[Rubilmax]

• Fixes Make accrueInterests public ? #129

[Rubilmax]

LGTM!

[Jean-Grimal]

I don't really get the utility of this function. Who would want to call it ?
I would rather have getters for asset amount that take interest accrued into account (which would only work if the Irm's borrowRate function is view)

[pakim249CAL]

I don't really get the utility of this function. Who would want to call it ? I would rather have getters for asset amount that take interest accrued into account (which would only work if the Irm's borrowRate function is view)

I'm pretty sure that some of the team is dead set on the borrow rate not being a view function. Therefore, this is the only way that we can have an updated total supply/total borrow for a market before executing any functions, which is important for integrators that would really like exact accounting.

[MerlinEgalite]

I don't really get the utility of this function. Who would want to call it ? I would rather have getters for asset amount that take interest accrued into account (which would only work if the Irm's borrowRate function is view)

I'm pretty sure that some of the team is dead set on the borrow rate not being a view function. Therefore, this is the only way that we can have an updated total supply/total borrow for a market before executing any functions, which is important for integrators that would really like exact accounting.

There might be a way to expose a borrowRate function that is view though. In this case, we wouldn’t such function and we could just create the relevant getters for integrators. @MathisGD might do a PoC once he's alive

[pakim249CAL]

For that paradigm to be secure, the view getter and the borrow rate non-view function must be ensured to always return the same result. This idea therefore seems to have the potential to become quite messy in the IRM implementation, and would require careful auditing.

IMO we should either make the borrow rate a view fn, or have an accrueInterest fn in Blue. I don't think we should try to do some weird thing that makes the IRM have two separate fns that could have the possibility to diverge from a mistake in the code.