feat: fix linear pricing migration

[wischli]

Description

• Bumps loans storage version from 3 to 4
• Adds migration for new with_linear_pricing handle of ExternalPrice struct
• To be checked: Sets with_linear_pricing true for all active (8 on mainnet) and created (1 on mainnet) loans

Please ignore temporary adjustments to tomls and the added logs, they are purely for debugging and will be removed!

TODO

• Fix arithmetic underflow error occurring during the nav update of the first asset already: When we call y_coord_in_rect in maybe_with_linear_accrual_price, we seem to have infeasible values:

• oracle_provided_at == price_last_updated == x1 = 1715869380
• price == y1 = 0
• maturity == x2 = 1715212800
• self.info.notional == y2 = 100000000
• T::Time::now() == x = 1715949888

Since x1 > x2, y_coord_in_rect performs x1.ensure_sub(x)? which throws because now is larger than the oracle timestamp x1. Logically, I don't think this could ever be right because the oracle timestamp should always be in the past?! So I imagine the order of the arguments of the y_coord_in_rect call is wrong here.

Logs

[2024-05-17T13:52:51Z WARN  pallet_loans::entities::pricing::external] current_price_inner: Seconds 1715212800, oracle Some((0, 1715869380568))
[2024-05-17T13:52:51Z WARN  pallet_loans::entities::pricing::external] maybe_with_linear_accrual_price: Seconds 1715212800, price 0, price_last_updated 1715869380
[2024-05-17T13:52:51Z WARN  cfg_utils::math] y_coord_in_rect: x1 1715869380, x2 1715212800, y1 0, y2 100000000, x: 1715949888
[2024-05-17T13:52:51Z ERROR runtime_common::migrations::loans] LoansMigrationToV4: error updating the portfolio for 4139607887: Arithmetic(Underflow)

Fixes #(issue)

Changes and Descriptions

[List your changes here]

Checklist:

• I have added Rust doc comments to structs, enums, traits and functions
• I have made corresponding changes to the documentation
• I have performed a self-review of my code
• I have added tests that prove my fix is effective or that my feature works

[lemunozm]

Just curious, are we sure we do not need to migrate ClosedLoan? Will the expected decoded vector with that empty value match the current structure?

[lemunozm]

After a second thought, I'm pretty sure we need migrate the ClosedLoan storage. We need to "reencoding" the on-chain values to be able to decode them fine later.

[wischli]

What I wanted to say: We only need to migrate if this storage is not empty. Right now, it is empty and it seems reasonable we can keep this state until upgrading Mainnet.

However, then I checked Demo and it has one entry. So yes, I will write a migration!

[lemunozm]

Ah ok, I didn't know it was empty in centrifuge

[wischli]

ClosedLoan migration added here: 833b9d1

[wischli]

@lemunozm There still seems to be an issue. We have surpassed the underflow error and now experience a DivisionByZero one:

[2024-05-23T09:47:41Z WARN  pallet_loans::entities::pricing::external] current_price_inner: Seconds 1715212800, oracle Some((0, 1715869380568))
[2024-05-23T09:47:41Z WARN  pallet_loans::entities::pricing::external] maybe_with_linear_accrual_price: maturity 1715212800, price 0, price_last_updated 1715869380
[2024-05-23T09:47:41Z WARN  cfg_utils::math] y_coord_in_rect: x1 1715212800, x2 1715212800, y1 0, y2 100000000, x: 1715212800
[2024-05-23T09:47:41Z ERROR runtime_common::migrations::loans] LoansMigrationToV4: error updating the portfolio for 4139607887: Arithmetic(DivisionByZero)

[lemunozm]

That loan has something peculiar, either or the current oracle price is 0, or it has been borrowed/repaid with 0 (I assume the last). Independently of the current issue. After adding this feature to that loan, the portfolio will have a significant change in its value. Are we ok? @mustermeiszer

[lemunozm]

@wischli great catch! It should be fixed now after you rebase the branch again. I've added more testing to hope checking everything... 😅

[lemunozm]

Thanks for your super migration on this!! Suuuper clean!