Implementing the dToken restart

[kuegi]

Summary

This PR contains the features needed for the "dToken restart"-DFIP.

I summarized all the implemented logic with additional reasoning in this video:
https://youtu.be/MdlbdXfkuY8

I build it to trigger on DF25 fork block, because IMHO this upgrade should have its own hardfork for extensive testing. I would not mix this into DF24.

Thx to Peter, it does no longer need to trigger on fork block, but based on attribute. So IMHO its fine to include in DF24 and trigger once fork is proven to be smooth (with timestamp and reward update) and extensive testing is successfull.

open issues

Since I do not know if you can/will take any of the given code, I did not include extensive error handling/logging yet and focused on getting the functionality in. (thanks to Peter, error handling was massively improved)

RPCs

added calls to interact with the tokenlock:

• listlockedtokens to get all currently locked tokens per account
• getlockedtokens to get all locked tokens for one account
• releaselockedtokens creates a tx to release a given part of the locked tokens (only allowed by foundation adresses)

Protocol

added implementation of locking 90% of dToken supply on fork block DF25:

• forced paying back all loans (using "payback dToken with DUSD" logic here to prevent liquidity issues in dToken-DUSD pools)
• "splitting" all loantokens (including DUSD) 1:1 to new tokens (needed to seperate DVM tokens and pre-lock EVM tokens)
• locking 90% of all loantokens (also DUSD collateral): moving them to native SC address, keeping track of balances in TokenLockUserValue
• removing 90% of LP in any loantoken-related pool, locking resulting loantokens

~note: the 90% is currently hardcoded. The DFIP states that it changes if DUSD rises drastically before activation. IMHO the ratio should be fixed when final release version gets released.

Also the DFIP states that it must not be activated if DUSD recovers completely before activation. So we should not merge this in too early, or at least have it in a way that its easily removed again. Maybe a precompiler gate?~

Implementation got changed to use the ratio from attribute, so this is flexible now, also the activation decision.

added logic to support dToken restart after fork

• TD of pre-lock-tokens (EVM->DVM) locks tokens according to current release ratio
• upgradeToken on EVM is prevented for pre-lock-token (must do TD, so no mix of DVM and EVM locks are necessary)
• handle lock on future dToken splits
• added tx to release locked tokens (based on defined criteria, these tx should be done manually IMHO)

updated PoolSplit logic

~current pool split logic has a small irregularity: MIN_LIQUIDITY is given to the last LP provider leaving the pool and taken from the first. I changed the logic to not iterate over all and remove/readd liquidity, but just move LP tokens accordingly and move all reserves at once. (this could be seperated in a different PR)~~

split out to seperate PR

Storage

• TokenLockUserValue to store locked balances per user
• economy variables v0/live/economy/locked_tokens and v0/live/economy/token_lock_ratio

Implications

• Storage

  • Database reindex required
  • Database reindex optional
  • Database reindex not required
  • None

• Consensus

  • Network upgrade required
  • Includes backward compatible changes
  • Includes consensus workarounds
  • Includes consensus refactors
  • None