Loans: ChangeGuard trait and loans modifications

[lemunozm]

Description

This PR overwrites #1222 with some simplifications.

• The mutation storage is no longer in pallet-loans. Now the implementor of ChangeGuard, is who should allocate those mutations. This way, we extract from pallet-loans and any future ChangeGuard's user the need to manage mutations with its own storage
• pallet-loans no longer has a dependency on CfgChange. The runtime is who transforms the LoanMutation type into a CfgChange that the implementor of ChangeGuard understand.

Fixes #1207

Changes and Descriptions

• Added ChangeGuard trait.
• Added ChangeGuard trait mock.
• Added 2 new extrinsic for loan modifications to pallet-loans.
• Added a utility to configure pallet-loans without the modification feature.
• Legacy tests passing
• Add new tests
• Runtimes working with the feature disabled

[lemunozm]

Important parts commented below:

[lemunozm]

This is the most essential part.

Each pallet has its own kind of change. They only know about its change. This ChangeGuardBridge transform that pallet-specific change into a CfgChange that the implementation of ChangeGuard knows.

The current implementation only merges those into one enum. But we could change them into a more detailed one, appending the moment when it happens or adding a severity level that ChangeGuard can understand.

[hieronx]

Clippy is failing but LGTM!

[lemunozm]

I've renamed the main functions of this feature to propose() and apply(), I think these names are more scalable for future applications. Examples:

let change = Change::Loan(loan_id, LoanMutation::InterestRate(...));
let change_id = Loans::propose(origin, pool_id, change)?;
Loans::apply(origin, pool_id, change_id);

But if you do not like or suggest others, please tell me.

[hieronx]

@lemunozm I do think these extrinsic names are a bit confusing 😅 Since the pallet name is loans, these will be loans.propose() and loans.apply(), which implies you are proposing and applying loans, rather than changes. Maybe just propose_change/mutation and apply_change/mutation?

[lemunozm]

I agree, it makes total sense what you say! 👍🏻

I'll add the suffix _change that I think fits better with the parameter name.

[mustermeiszer]

LGTM! Gives us enough flexibility for future changes and we can channel down core changes to the pool-system and let the rest be handled by the ChangeGuard impl

[lemunozm]

This is new. It checks that the modification can be applied, at least when it is proposed. It doesn't mean later it can be applied or not, but at least it removes most of the bad usages for it, for example, trying to modify the interest rate in external pricing. If we don't check this, the change will be enqueued, and we will get the error weeks later.

This is not 100% reliable, because once the change can be applied, the loan could have been closed, or its state changed. i.e:

let change_id_1 = Loans::propose_loan_mutation(DCF::DiscountRate(0.2)); // ==> Ok
let change_id_2 = Loans::propose_loan_mutation(ValuationMethod::OutstandingDebt); // ==> Ok

// Time passes and both proposals become available to be applied

Loans::apply_change(change_id_2); // ==> Ok
Loans::apply_change(change_id_1); // ==> MutationError::DiscountedCashFlowExpected

[hieronx]

That's a great idea! We definitely should incorporate the same in pool-system

[lemunozm]

This is ready for a final review 🤓

[hieronx]

LGTM!