feat: guide user to call a parachain

[AlexD10S]

This PR introduces the pop call parachain command, providing guidance for users to interact with a chain. The approach to achieving a great DevEx is to start with a list of specific use cases that we believe will be most useful for developers, such as creating an asset, nfts, and other interesting developer focused actions, while also allowing them to access a broader range of extrinsics.

┌   Pop CLI : Call a parachain
│
◇    Which chain would you like to interact with?
│  ws://localhost:9944/
│
◆  What would you like to do?
│  ○ Transfer balance 
│  ○ Create an asset 
│  ○ Mint an asset 
│  ○ Create an NFT collection 
│  ○ Mint an NFT 
│  ● All (Explore all pallets and extrinsics)
└  

pop-cli also offer a the command-line interface for direct execution. For example to mint an NFT directly: pop call parachain --pallet Nfts --extrinsic mint --args "1" "1" "Id(5FHneW46xGXgs5mUiveU4sbTyGBzmstUspZC92UhjJM694ty)" "None()" --url ws://localhost:9944/ --suri //Alice

Additional PRs:

To simplify the review process, some functionality has been split out from this main PR:

• Submit extrinsic indicating the call_data: feat: submit extrinsic from call_data #348
• Wrap the selected call as a sudo call: feat: flag sudo to wrap extrinsic #349
• Parse files when the argument values are very big feat: parse files when the argument values are very big #363
  There is a limitation on the input size in the CLI, which may cause the process to fail if the input string is too large. For instance, this issue can occur when using the register extrinsic:

◇  What would you like to do?
│  Register a parachain ID with genesis state and code 
│
◇  Enter the value for the parameter: id
│  2000
│
◇  Enter the value for the parameter: genesis_head
│  0x000000000000000000000000000000000000000000000000000000000000000000fc3a2a9c95d7e6cfc871d72111eb7af5c30da67f1b8ef35ff4eb346c9483201e03170a2e7597b7b7e3d84c05391d139a62b157e78786d8c082f29dcf4c11131400
│
◆  Enter the value for the parameter: validation_code
│  Type required: [u8]
└  

Review Considerations

• Some extrinsics are not supported yet due to the complexity of input the parameters. Example: A sudo call where another call has to be inputted by a command line:

- ◇  Select the pallet to call:
│  Sudo 
│
◇  Select the extrinsic to call:
│  sudo 
│
└  The selected extrinsic is not supported yet. Please choose another one.

For a better DevEx this will functionality will be supported using a flag to indicate it (#349).

• Some file changes occurred because this feature required files originally in the pop_contracts crate. Functions like create_signer, format_type and find_free_port were moved to the pop_common crate to make them accessible in the pop_parachain crate.

• The way the extrinsic arguments are prompted here is an improvement over the pop call contract functionality. In this implementation, we present Variants (Enums) as a selectable list with different options and individually prompt for all the fields of a Composite (Struct) type, constructing it for the user. If approved, this approach can be reused later to improve the experience in pop call contract as well.

[sc-1314] [sc-1515]

[brunopgalvao]

Preliminary UX Feedback:


◇  Which chain would you like to interact with?
│  wss://rpc1.paseo.popnetwork.xyz

How does the user know what Pop CLI supports for chain calls? e.g. minting NFTs, minting assets? etc.

Make the UX around what is possible to do on Polkadot, and secondarily, what chains support those operations.

For example:



◆  What would you like to do on Polkadot?
│  ● Create an asset
│  ○ Mint an asset 
│  ○ Create an NFT collection 
│  ○ Mint an NFT from an existing collection
│  ○ Transfer tokens from one account to another 
└  


◆  Supported Polkadot chains:
│  ● Pop Network
│  ○ Phala
│  ○ Acala
│  ○ Moonbeam
│  ○ Custom RPC
└  



◆  On which Relay network?
│  ● Pop Network on Paseo (Polkadot’s Test Network)
│  ○ Pop Network on Polkadot
└  


[AlexD10S]

Preliminary UX Feedback:


◇  Which chain would you like to interact with?
│  wss://rpc1.paseo.popnetwork.xyz

How does the user know what Pop CLI supports for chain calls? e.g. minting NFTs, minting assets? etc.
 Make the UX around what is possible to do on Polkadot, and secondarily, what chains support those operations.

For example:



◆  What would you like to do on Polkadot?
│  ● Create an asset
│  ○ Mint an asset 
│  ○ Create an NFT collection 
│  ○ Mint an NFT from an existing collection
│  ○ Transfer tokens from one account to another 
└  


◆  Supported Polkadot chains:
│  ● Pop Network
│  ○ Phala
│  ○ Acala
│  ○ Moonbeam
│  ○ Custom RPC
└  



◆  On which Relay network?
│  ● Pop Network on Paseo (Polkadot’s Test Network)
│  ○ Pop Network on Polkadot
└  


I don't personally like to have a list of chains. The users of this feature are devs, so in my opinion, the pop call parachain command is most useful when devs are actively working on a chain or smart contract and need to interact with it quickly.

For example, if I’m deploying a smart contract on the Pop Network that interacts with an NFT, I would want to run pop call parachain --pallet nft --extrinsic mint to mint the NFT locally or on a testnet with only 1 command. Similarly, if I need to test an XCM call, I may want to quickly fund an account on the relay chain.

For these two scenarios, I believe the current flow works best: first selecting the chain you are working on, and then focusing on the specific use cases available through pop-cli. However, the change in the order you're proposing is relatively easy to implement. So, if we still believe it offers a better DevEx, I can make the adjustment.

[brunopgalvao]

I don't personally like to have a list of chains. The users of this feature are devs, so in my opinion, the pop call parachain command is most useful when devs are actively working on a chain or smart contract and need to interact with it quickly.

For example, if I’m deploying a smart contract on the Pop Network that interacts with an NFT, I would want to run pop call parachain --pallet nft --extrinsic mint to mint the NFT locally or on a testnet with only 1 command. Similarly, if I need to test an XCM call, I may want to quickly fund an account on the relay chain.

For these two scenarios, I believe the current flow works best: first selecting the chain you are working on, and then focusing on the specific use cases available through pop-cli. However, the change in the order you're proposing is relatively easy to implement. So, if we still believe it offers a better DevEx, I can make the adjustment.

If the audience are devs, it makes sense what you are saying:

1. Input a chain RPC URL
2. Show what features are available

I would still have Pop Network as a default, pre-defined chain. So the flow would be like this:


◆  Which network would you like to interact with?
│  ● Pop Network
│  ○ Custom RPC
└  


The following will be shown if the user selects "Pop Network":


◆  On which Relay network?
│  ● Pop Network on Paseo (Polkadot’s Test Network)
│  ○ Pop Network on Polkadot
└  


The following will be shown if the user selects "Custom RPC":


◆  Enter a custom RPC URL:
│  e.g. rpc1.paseo.popnetwork.xyz
└  



◆  The following features are available on the selected network:
│  ● Create an asset
│  ○ Mint an asset 
│  ○ Create an NFT collection 
│  ○ Mint an NFT from an existing collection
│  ○ Transfer tokens from one account to another 
└  

[Daanvdplas]

A few last nitpicks but the PR is looking fantastic, well done!

[al3mart]

Thanks for addressing my last comments. This is great!

[al3mart]

[sc-1841]

[evilrobot-01]

All proposed fixes from review have been merged so happy to approve now. Thanks for you patience in addressing everything, glad to see this complete.

Thanks for all your hard work on this Alex!