feat: Migrate pallets from standalone chain that was updated to common branch 'polkadot-v0.9.17' progressively

[ltfschoen]

• - Migrated all relevant pallets from DataHighway standalone chain PR feat: MMD-1309 / Update from Substrate 3 to commit dated 10th Feb 2022 (common branch 'polkadot-v0.9.17' for use with substrate-parachain-template) node#215, which fixes the block delay by switching from Babe to Aura, and also updates to Substrate branch 'polkadot-v0.9.17' from the substrate-parachain-template dated 10th Feb 2022
  • - Switched from using a commit rev = '...' to using latest branch for parachain branch = 'polkadot-v0.9.17'
• - Omited the following pallets from parachain since only relevant on standalone chain: pallet-grandpa, pallet-im-online, pallet-election-provider-multi-phase, pallet-offences, pallet-staking, pallet-staking-reward-curve, pallet-bags-list, pallet-authority-discovery, frame-election-provider-support, sp-npos-elections, sp-transaction-storage-proof, sp-staking, sp-keyring, sp-authority-discovery
• - updated script ./scripts/init.sh to nightly-2021-12-15
• - Reset versions in Cargo.toml files and other parameters like spec_version and impl_version
• - Find out how to replace pub type Address = MultiAddress<AccountId, ()>; with pub type Address = MultiAddress<AccountId, AccountIndex>; like on standalone chain
  • - Why do we get error when copy impl<LocalCall> frame_system:', impl frame_system::offchain::SigningTypes, impl frame_system::offchain::SendTransactionTypes`, into implementation https://substrate.stackexchange.com/questions/613/what-does-trait-checkablechaincontextruntime-do-i-need-it-as-a-trait-bound
    Update: I've created this PR to try and incorporate the change feat: Update MultiAddress with AccountIndex  #19, since i believe these changes are necessary to make transfers, but it generates an error as shown in the description of the PR, and i've asked for help here https://substrate.stackexchange.com/a/725/83
    Update: Closing this item as it doesn't appear to be necessary as other live parachain projects aren't using it. See comments here Refactoring work #20
• - Modify parachain constants/parameters for each pallet and the runtime (for example, if we want democracy proposals to take 1 week instead of 1 month then change the parameter otherwise we will have to wait that long to make that change when the chain is live unless we use sudo)
• - check that it runs using polkadot-launch by following these steps https://github.com/DataHighway-DHX/documentation/blob/master/docs/tutorials/tutorials-node-polkadot-launch-datahighway-rococo-local.md
  • - it was failing with error when it tries to export-genesis-state

⛓ Adding Genesis Parachains
Error: Command failed: /Users/ls2/code/DataHighway-DHX/polkadot-launch/bin/datahighway-collator export-genesis-state --chain=rococo-local
thread 'main' panicked at 'the balance of any account should always be at least the existential deposit.', /Users/ls2/.cargo/git/checkouts/substrate-7e08433d4c370a21/22d40c7/frame/balances/src/lib.rs:586:17

The cause of this problem is because the EXISTENTIAL_DEPOSIT is currently 1000000000000000, (i.e. 100 * MILLICENTS), but some of the balances in the hardspoon accounts that we are trying to import from the standalone chain had less than the existential deposit.
Fixed in this PR DataHighway-DHX/open-polkadot-js-library#8, and copied the latest data/ that was generated into the genesis.json, and that fixed the issue.

• - check that all essential pallet functionality works using polkadot.js
  • - balances - make transfers between accounts, hard spooned balances transferred from standalone to parachain
  • - democracy - create a preimage to transfer funds and use that preimage hash to create a proposal
  • - treasury - check 30 million DHX balance hard spooned from standalone to parachain
  • - sudo - check that sudo works for forceTransfer and setBalance
  • - staking - check that able to add additional collator nodes and they generate and finalize blocks
  • - runtime upgrade - check that able to perform a runtime upgrade when running rococo-local with a collator after minimizing the runtime size without the transaction exhausting the block limit https://docs.substrate.io/tutorials/v3/forkless-upgrades/#schedule-an-upgrade

sudo.sudoUncheckedWeight
1010: Invalid Transaction: Transaction would exhaust the block limits

The runtime upgrade check where I only changed the existential deposit value generated a .compact.wasm file that was 6MB in size, so it was necessary to reduce it to less than 3.1MB. I have reduced the runtime size to 3.05MB so can perform runtime upgrades in PR #24
*
* [X] - metadata - check that no errors in polkadot.js using custom_types.json

• - Check that 'block delay' issue is fixed since we are now using Aura instead of Babe. block time varies between 18-30 seconds for a block time of 12 seconds https://github.com/DataHighway-DHX/open-polkadot-js-library/blob/main/block-delay/backup/data-datahighway-rococo-local-aura/datahighway-rococo-local-testnet-2022-03-15-11:17-744000000.csv
• - Add scripts to codebase to simplify dumping chain specs, state and wasm for all relevant chains (use these ones https://github.com/integritee-network/parachain/blob/master/scripts/dump_wasm_and_state_for_all_chains.sh)
• - Fix treasury-dao and mining-lodgements-hardware that are missing Cargo.toml files
• - Add benchmarking
• SKIPPED - Runtime Benchmarking for Proper Weights
  • Unable to run benchmarks with cargo build --release --features runtime-benchmarks, as it gives the following erorr even though we're not evening using frame society, and even though successful_origin is already implemented in that branch here https://github.com/paritytech/substrate/blob/22d40c7/frame/society/src/lib.rs#L1278

error[E0046]: not all trait items implemented, missing: `successful_origin`
    --> /Users/ls2/.cargo/git/checkouts/substrate-7e08433d4c370a21/22d40c7/frame/society/src/lib.rs:1268:1
     |
1268 | impl<T: Config> EnsureOrigin<T::Origin> for EnsureFounder<T> {
     | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `successful_origin` in implementation
     |
     = help: implement the missing item: `fn successful_origin() -> OuterOrigin { todo!() }`

Similar to this issue paritytech/substrate#10548
I have asked in "Builders Program - Chains Track" what Basti meant was required when he said: "forward the enabling of the runtime-benchmarks feature"

• - Add try-runtime and essential hooks
• SKIPPED - Test try-runtime to check amount of accounts remains the same after an on-chain upgrade
  https://docs.substrate.io/how-to-guides/v3/tools/try-runtime/
  https://docs.substrate.io/v3/tools/try-runtime/

Unable to run `cargo build --release --features=try-runtime

  error: the wasm32-unknown-unknown target is not supported by default, you may need to enable the "js" feature. For more information see: https://docs.rs/getrandom/#webassembly-support
     --> /Users/ls2/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.5/src/lib.rs:229:9
      |
  229 | /         compile_error!("the wasm32-unknown-unknown target is not supported by \
  230 | |                         default, you may need to enable the \"js\" feature. \
  231 | |                         For more information see: \
  232 | |                         https://docs.rs/getrandom/#webassembly-support");
      | |________________________________________________________________________^

  error[E0433]: failed to resolve: use of undeclared crate or module `imp`
     --> /Users/ls2/.cargo/registry/src/github.com-1ecc6299db9ec823/getrandom-0.2.5/src/lib.rs:256:5
      |
  256 |     imp::getrandom_inner(dest)
      |     ^^^ use of undeclared crate or module `imp`

I thought it may be necessary to upgrade to v0.9.18, but I tried that in this PR and that didn't work #22

• - check that unit and integration tests still pass
• SKIPPED - Memory Profiling (see Parachain Migration Plan). the guide at https://docs.substrate.io/v3/tools/memory-profiling/#hooking-to-a-manually-launched-substrate shows how to attach the profiler to the substrate binary. but i tried attaching it to our parachain binary but it didn't log .dat or .log files. we could try later to see if it records logs when attached to the substrate-node-template rather than something based off the substrate-parachain-template
• - Minimize Runtime Size (see Parachain Migration Plan). See error when trying to perform a runtime upgrade https://docs.substrate.io/how-to-guides/v3/parachains/pre-launch/#3-minimize-your-runtime-size
  I have reduced the runtime size so can perform runtime upgrades in PR feat: Minimize runtime size to allow for runtime upgrades #24
• - Run Collator bootnode and generate chain spec, "raw" chain definition, export genesis state, export genesis wasm, and copy ./target/release/wbuild/datahighway-parachain-runtime.compact.wasm and store in /res folder for the latest changes in this PR for the parachains, since this may be used by other collators
  • - rococo_local
  • - rococo
  • - tanganika
• - generate new Github release (use contents of this checklist to mention what was done) and deploy to Rococo, and Tanganika
  DRAFT RELEASE MESSAGE

v3.2.0

## What's Changed

* Updated version of datahighway-collator and datahighway-parachain-runtime packages to 3.2.0
* Migrated all relevant pallets from DataHighway standalone chain PR https://github.com/DataHighway-DHX/node/pull/215, which fixes the block delay by switching from Babe to Aura, and also updates to Substrate branch 'polkadot-v0.9.17' from the substrate-parachain-template dated 10th Feb 2022
  * Switched from using a commit `rev = '...'` to using latest branch for parachain `branch = 'polkadot-v0.9.17'`
* Omited the following pallets from parachain since only relevant on standalone chain: pallet-grandpa, pallet-im-online, pallet-election-provider-multi-phase, pallet-offences, pallet-staking, pallet-staking-reward-curve, pallet-bags-list, pallet-authority-discovery, frame-election-provider-support, sp-npos-elections, sp-transaction-storage-proof, sp-staking, sp-keyring, sp-authority-discovery
* Updated script ./scripts/init.sh to nightly-2021-12-15
* Reset versions in Cargo.toml files and other parameters like `spec_version` and `impl_version` 
* Replaced `pub type Address = MultiAddress<AccountId, ()>;` with `pub type Address = MultiAddress<AccountId, AccountIndex>;` like on standalone chain. Received help here https://substrate.stackexchange.com/a/725/83
* Modify parachain constants/parameters for each pallet and the runtime (for example, if we want democracy proposals to take 1 week instead of 1 month then change the parameter otherwise we will have to wait that long to make that change when the chain is live unless we use sudo)
* Checked that it runs using polkadot-launch by following these steps https://github.com/DataHighway-DHX/documentation/blob/master/docs/tutorials/tutorials-node-polkadot-launch-datahighway-rococo-local.md
  * It was failing with error when it tries to export-genesis-state. The cause of this problem was because the EXISTENTIAL_DEPOSIT was currently 1000000000000000, (i.e. 100 * MILLICENTS), but some of the balances in the hardspoon accounts that we are trying to import from the standalone chain had less than the existential deposit. This was fixed in this PR https://github.com/DataHighway-DHX/open-polkadot-js-library/pull/8, and copied the latest data/ that was generated into the genesis.json, and that fixed the issue.
  * Checked that all essential pallet functionality works using polkadot.js
    * Balances - transfers between accounts, checked hard spooned balances transferred from standalone to parachain
    * Democracy - created a preimage to transfer funds and use that preimage hash to create a proposal
    * Treasury - checked 30 million DHX balance hard spooned from standalone to parachain
    * Sudo - checked that sudo works for forceTransfer and setBalance. This is necessary since the endowed amount of 10 DHX is not sufficient to pay the runtime upgrade fee of approx 30 DHX.
    * Staking - checked that able to add additional collator nodes and they generate and finalize blocks
    * Runtime Upgrade - checked that able to perform a small runtime upgrade when running rococo-local with a collator after minimizing the runtime size to less than the Rococo `maxCodeSize` of 3.1 MB without the transaction exhausting the block limits. Kusama will need to be used for incremental runtime upgrades to restore the pallets that were temporarily removed since it has a `maxCodeSize` of 10 MB. See comments [here](https://substrate.stackexchange.com/questions/784/why-is-the-rococo-maxcodesize-too-small-to-do-adequate-incremental-runtime-upg)
    * Metadata - checked that no errors in polkadot.js using custom_types.json
* Check that 'block delay' issue is fixed since we are now using Aura instead of Babe. block time varies between 18-30 seconds for a block time of 12 seconds https://github.com/DataHighway-DHX/open-polkadot-js-library/blob/main/block-delay/backup/data-datahighway-rococo-local-aura/datahighway-rococo-local-testnet-2022-03-15-11:17-744000000.csv
* Added scripts to codebase to simplify dumping chain specs, state and wasm for all relevant chains (use these ones https://github.com/integritee-network/parachain/blob/master/scripts/dump_wasm_and_state_for_all_chains.sh)
* Fixed treasury-dao and mining-lodgements-hardware that are missing Cargo.toml files
* Added benchmarking
* Skipped running benchmarking. See reasons in conversation https://github.com/DataHighway-DHX/DataHighway-Parachain/pull/17
* Added try-runtime and essential hooks
* Skipped running try-runtime to check amount of accounts remains the same after an on-chain upgrade. See reasons in conversation https://github.com/DataHighway-DHX/DataHighway-Parachain/pull/17
* Checked that unit and integration tests still pass
* Skipped Memory Profiling. See reasons in conversation https://github.com/DataHighway-DHX/DataHighway-Parachain/pull/17
* Minimize Runtime Size by checking critical parachain constraints and temporarily removing some pallets that will be restored again later on Kusama as incremental runtime upgrades https://docs.substrate.io/how-to-guides/v3/parachains/pre-launch/#3-minimize-your-runtime-size

The following is the output of checking the configuration of Rococo relay chain

  maxCodeSize: 3,145,728
  maxHeadDataSize: 32,768
  maxPovSize: 5,242,880

The runtime upgrade check where I just changed the existential deposit value generated a .compact.wasm file that was 6MB in size, so it was necessary to reduce it to less than 3.1MB. I have reduced the runtime size to 3.05MB so can perform small runtime upgrades in PR #24. The community has been asked why the Rococo `maxCodeSize` is smaller than Kusama's here https://substrate.stackexchange.com/questions/784/why-is-the-rococo-maxcodesize-too-small-to-do-adequate-incremental-runtime-upg
* Generate the chain spec, "raw" chain definition, exported genesis state, exported genesis wasm using scripts in the /scripts folder from the first collator bootnode server. Copy them into a subfolder in the /res folder (i.e. /res/v3.2.0). Also copy the built DataHighway-Parachain/target/release/wbuild/datahighway-parachain-runtime.compact.wasm file into the /res folder, and then push them as a commit to Github. This process should also be performed for runtime upgrades so they are distributed to all collators and bootnodes so they have the latest changes. 

**Full Changelog**: https://github.com/DataHighway-DHX/DataHighway-Parachain/commits/v3.2.0

[ayushmishra2005]

Please create github issue for pending tasks and link with this PR.

[ayushmishra2005]

Please fix indentation everywhere in this file