feat: skip delisted yangs for value and price update

[tserg]

Partially addresses L-02 of https://github.com/code-423n4/2024-01-opus-findings/issues/85

Once a yang is delisted, its value will no longer be taken into account and price updates will be skipped. This also means that the base rate will no longer be relevant for interest accrual in troves with the delisted yang.

For redistributions, delisted yangs will be redistributed exceptionally by accruing to the protocol even though they do not account for any value. In the edge case where a trove has deposited only delisted yangs, the entire trove's debt will also be transferred to the protocol.

[tserg]

Note to self: To handle redistributions involving troves with suspended yangs - since suspended yangs do not count towards a trove's value, they can also be skipped during redistribution.

[UPDATE - This could have merge conflicts with #532, and would be more manageable if this goes after]

[tserg]

I realized that we cannot skip a delisted yang for redistribution. In the case where a trove with non-zero debt has deposited only a delisted yang, then doing so will render redistribution useless because the debt is incapable of being redistributed.

I think the appropriate way to handle redistribution of delisted yang is to handle it like exceptional redistributions - transfer the yang and debt to be owned by the protocol.

[tserg]

I can't remember where, but we had this discussion about recursion limits (I think it was a problem raised by a warden in some analysis in the C4 audit). It arises here as well - imagine we have permanently suspended yang Y, a trove T has it, but not a lot, so it doesn't cause any issues. Then, after a looooong time after Y's suspension, the owner of T does some operation (deposit, withdraw, doesn't matter) which internally runs get_recent_price_from - but since Y is suspended, it didn't have a price update for a lot of intervals. Can that become a problem (e.g. us hitting recursion limit)? I can't remember what we've concluded when we discussed about it.

Yes, that would be a real issue. The situations that we need to handle to prevent this from becoming an issue would be (1) calculating threshold and value; and (2) when calculating accrued interest in get_avg_rate_over_era.

[milancermak]

Couldn't come up with a better solution but - what if, when the yang is permanently suspended, we call get_current_yang_price in Seer and use that to advance? 🙊 Essentially using the last price (which is implicitly happening anyway), but preventing the recursion issue?

[milancermak]

As discussed on Slack, we should disregard the idea above (it never happened 🙈) and use 0 as the recent price in get_recent_price_from. Even though an asset will most probably have a non zero value outside of Opus, for all intents and purposes, when a yang is permanently suspended it doesn't have any value for the protocol.