Feature/plmc 391 allow parallel instantiaton of projects

[JuaniRios]

What

1. Every participant has to make a one-time deposit to cover their pallet-assets storage for each contribution token. Linear issue
2. When compiling the node with std, we can now define a genesis config of pallet-funding, which will instantiate any project at any stage, with any participations/evaluations. The syntax is the same as used in the Instantiator. Linear issue
3. The Issuer needs to pay for the ExistentialDeposit of the escrow account for their project. Found the bug while doing the previous item.

Why

1. This fixes the problem where a participant could only have a limited amount of different (i.e separate projects) contribution tokens related StackExchange post
2. To start testing the blockchain with the UI, we need to spin up projects at different stages several times. Now we avoid wasting time manually creating every project every time we spin up a node.
3. Accounts need always some minimal deposit to exist. We didn't catch this bug before because the derivation for escrow accounts we used made it so the escrow for project 0, was equal to the pallet-funding system account. And that one we always funded at Genesis.

How

1. In every participation and evaluation extrinsic, we check if the user has already a deposit for that project_id. If not we reserve it for him. That amount will be used to call the touch() extrinsic of pallet-assets which pays for storage, if the project succeeds. If the project fails then it is returned to the user.
   The return has been implemented in the Cleaner.
2. New asynchronous functions now live in the instantiator. We have a controller which is in charge of advancing blocks, and resuming execution of the different project creation functions that live in separate tasks.
   This way, before continuing advancing blocks for a project, we can stop and resume execution of other projects that wanted to execute in that block.
3. When calling create(), the amount is transferred from the issuer to the escrow, which will make the extrinsic fail if the issuer doesn't have enough funds

Testing

1. ct_account_deposits_are_returned tests written for evaluations, bids, and contributions. They test both the locking up and the automatic release of the plmc when the project fails.
2. There are 2 tests created when prototyping which use different abstraction levels (prototype_1(), prototype_2()). And one test which calls the genesis config, which is the outcome we wanted to test (genesis_parallel_instantiaton()).
   It happened that the genesis pallet test passed, but when running the real node it failed. Because of this also a test inside integration-tests was written, which calls the node directly and tries building the raw spec. It lives inside build_spec.rs. Note you should have the node compiled with std (and fast-gov to make it faster) at the target/release folder.
3. issuer_cannot_pay_for_escrow_ed tests that the creation function fails if the issuer doesn't have enough funds to pay to the escrow for its creation

Anything else?

1. Maybe I should write a test that the ct deposit was used successfully. But this is tested already in every project creation function when checking for correct balances before and after creation.
3. Note that USDT and USDC pallet-asset accounts will be created by increasing the consumer account of that escrow. But since we don't expect many funding assets at the beginning, it should be fine for now.

Addendum

• Testing-node feature is now removed. The "std" flag should be used to be able to pass an externality to the instantiator
• Benchmarks on pallet-funding are broken, but will be fixed in PLMC-373

[vstam1]

I think there are two big things that I like to discuss with you:

1. Lets go over the multiple project instantiation together as its not completely clear to me how it works with async/multithread instantiation.
2. As far as I currently understand we add a list of accountIds to the projectDetails storage via the cleaner. Not completely sure how it encodes it in scale but if it would encode all the accountIds that still need to be refunded for ct deposit, it would bloat the total storage of the ProjectDetails. If we really need to store it instead of calculating it on the fly, I would like to see it getting stored in a separate storage item.

[lrazovic]

This should remove the warnings at compile time.

(Please test if everything still works. I tested with cargo b -r and cargo b -r --features std, but I may missed some other features)

Suggested change

	use pallet_funding::{instantiator::UserToUSDBalance, *};
	#[cfg(all(feature = "testing-node", feature = "std"))]
	use sp_runtime::BoundedVec;
	#[cfg(all(feature = "testing-node", feature = "std"))]
	#[cfg(feature = "std")]
	mod testing_helpers {
	use super::*;
	use frame_benchmarking::frame_support::assert_ok;
	use macros::generate_accounts;
	use polimec_parachain_runtime::AccountId;
	use sp_core::H256;
	use sp_runtime::traits::ConstU32;
	use sp_runtime::{traits::ConstU32, FixedU128};
	use std::collections::HashMap;
	mod testing_helpers {
	use super::*;
	use macros::generate_accounts;
	pub use pallet_funding::{instantiator::UserToUSDBalance, *};
	use polimec_parachain_runtime::AccountId;
	use sp_core::H256;
	pub use sp_runtime::{traits::ConstU32, BoundedVec, FixedU128};

[JuaniRios]

addressed in c3f801e

[lrazovic]

I focused my review on the no-std part and the node, since I don't have enough experience with tokio to give a valuable feedback, but from what I have seen it looks definitely interesting.

We can probably improve the propagation of the std feature in the node since it should be on by default at that stage. Maybe we can take a cue from https://github.com/KILTprotocol/kilt-node/blob/b8a22b85fad24d88c2849f6430f8b6019522fd25/nodes/parachain/Cargo.toml#L52-L63

Nevertheless LGTM, with only one nit: #130 (comment)