Feature/plmc 290 xcm instruction that reveals polimecs balance and pallet

[JuaniRios]

Objective

• Do necessary checks to make sure we can start the migration of CT tokens without failing.

Tech

• Excute XCM instructions QueryPallet and ReportHolding on the project chain after HRMP has been established
• Receive the response on pallet-funding and evaluate that ReportHolding returns enough native tokens to migrate, and the polimec receiver pallet is there to use.
  • Note that right now we expect a full struct of PalletInfo because the fields are private and we cannot retrieve values and compare/store them. More importantly this means we have to expect the pallet to have a certain index which is dumb, but will be addressed in Polkadot-SDK PR #2231, after which we can store the index and use it for the migration.

Main Changes

• New extrinsics:
  • start_migration_readiness_check: called automatically when HRMP is established, and by the issuer when the check failed, so we can retry.
  • migration_check_response: called by the chain after processing our QueryPallet and ReportHolding instructions.
• HRMP logic moved to a do_function called by the xcm-executor impl.
• Custom penpal added to the emulator, because we need to get free execution by the target chain. This is a design decision we should discuss.
  • My thinking is that the polimec soverign account should hold EXACTLY the amount of CT bought, so there's no confusion. And the migration should not be paid by us.
  • This includes the issuer adding enough tokens to pay for execution on the Polimec account, because then we cannot ensure all the transactions will go through.
  • We could argue that the fact that we can execute for free the query, does not mean we can execute for free all migrations, so maybe we should implement a dummy migration to check that it passes the barrier too.
• New Polimec receiver pallet that is now a pallet-template but is used for querying its existence.
• pallet-xcm is now tightly coupled to pallet-funding. This is because we need to let pallet_xcm know we expect a query response, before the executor receives that instruction. Open to any solutions that allow us to decouple it.
  • This means we also need to implement pallet xcm and executor in the mock runtime of pallet-funding. Even though we shouldn't use any xcm features on pallet tests since xcm does not work there.
• A new integration test on the emulator for the query and response behaviour.
  • For this we needed the Instantiator, and we couldn't access it through the test config, so I did the quick approach which is the other access of both "std","testing-node". This means we cannot call the tests just by doing cargo test, but need to call cargo test --features std,testing-node. For more info why, check this link
  • Since the HRMP establishement we implemented in Feature/plmc 287 parachain information discovery and channel opening #94 is not possible to replicate in the emulator (because the emulator mocks the actual messaging protocol), we had to go around it by mocking the behaviour.
  • Small format changes

[linear]

PLMC-290 Xcm instruction that reveals Polimec's balance and pallet existence

[JuaniRios]

/bot fmt

[github-actions]

fmt: Failed ❌
https://github.com/Polimec/polimec-node/actions/runs/6822625402

[lrazovic]

Just few nitpicks that I would love to address offline, but overall a huge new set of feature towards the MVP!

[vstam1]

lgtm with the changes requested by Leonardo. I do not really like the tight coupling on pallet-xcm, but I do not really see another way without implementing the same logic as pallet-xcm with adding a callback on query response.