Implement AMM 2.0-light

[maltekliemann]

What does it do?

Implements AMM 2.0-light according to internal design documents.

What important points should reviewers know?

• Math functions taken from HydraDX because we need exponential for negative numbers and ln for values < 1.
• https://doc.rust-lang.org/book/ch11-03-test-organization.html used for test organization
• Going by the view that extrinsic function bodies are for signing and weight logic only and should call into a do_* function, which should contain absolutely no signing or weight logic. Sometimes this results in a double DB reads. A solution is proposed here: Research performance cost of duplicate reads and implement a solution if necessary #1081
• All test data created using Python playground
• I found multiple bugs in the to_fixed_decimal conversion: 0.99999999999999999 converts to 0.1 and 2.075187496394219092731299 converts to 0.2751874964. I've found it easier to rewrite the entire function. Because this is a very touchy situation, I suggest taking an extra close look at the new implementation (failed conversions are far worse that rounding errors!). Mistakes could be disastrous.
• I've tried to make as little changes to other pallets as possible. This sometimes results in awkward code duplication. This will most likely get better when AMM 2.0 is implemented completely.
• One particular instance where I avoided unncessary work is with destroying markets. LMSR pools are closely tied to the underlying market since they make use of the buy/sell complete set operations. As luck (?) would have it, every extrinsic except exit requires a market to exist. Thus, destroying the underlying market makes the pool defunct. I see no need to make any changes to market destruction.
• The formatting is god-awful in some places. This is because we're using the nightly version of rustfmt, which is pretty broken. Nothing I can do here except raising issues on rustfmt.
• I've taken a few shortcuts when extending prediction-markets. In particular, I've deleted the extra_weight stuff because it's Rikiddo-only.
• I'm double-booking the reserve of the pool in the Pool struct to avoid griefing attacks: Sending funds to the pool can be used to change balances and thus prices. Doesn't seem to be profitable, but certainly very annoying.
• When creating a pool which uses the native currency as collateral, I'm depositing the existential deposit to avoid problems where a small fee amount < ED is sent to an empty pool account and the entire transaction errors out. This doesn't affect non-native collateral because we're just whitelisting these accounts from dust collection. Native currency doesn't seem to support whitelisting, although I'm getting mixed signals (or I'm just dumb): Add a dust removal whitelist to pallet-balances paritytech/polkadot-sdk#227, https://substrate.stackexchange.com/questions/9824/reaping-vs-dusting-and-how-to-whitelist-an-account.

Is there something left for follow-up PRs?

Follow-up PRs will do the following:

• Add detailed README and LaTeX docs explaining the formulas used in math.rs.
• Update zrml-prediction-markets benchmarks and define zrml-neo-swaps benchmarks
• Add RPC calls
• Include NeoSwaps in the runtime

What alternative implementations were considered?

None.

Are there relevant PRs or issues?

Strangely enough, this PR doesn't close any issues. Please refer to the design document for more details.

References

Things I've Learned

• When you abstract functions into traits which the pallet or outside structs implement, make the traits generic over Config. Don't be a hero and try to make the struct independent of Config. Otherwise, type inferrence and error handling is an utter mess.
• This is the last time I will ever avoid adding magic numbers to tests. A test with 50+ lines is virtually unreadable and completely obfuscates what's actually going on. Better to just provide magic numbers and point reviewers to the prototype which produces the values.
• It's probably a dumb idea to mix storage reads and non-pallet structs like Pool.

[mergify]

This pull request is now in conflicts. Could you fix it @maltekliemann? 🙏

[sea212]

LGTM, however I would separate the weight updates into another PR as they bloat the merge commit with unrelated changes.

[mergify]

This pull request is now in conflicts. Could you fix it @maltekliemann? 🙏