Add cli commands for the coinswap module.

[aayushijain23]

ref #4443
Adding cli-commands for the coinswap module.
PLEASE NOTE: This PR is up for code review and is not intended to be merged into the master atm.

• Targeted PR against correct branch (see CONTRIBUTING.md)

• Linked to github-issue with discussion and accepted design OR link to spec that describes this work.

• Wrote tests

• Updated relevant documentation (docs/)

• Added a relevant changelog entry: clog add [section] [stanza] [message]

• rereviewed Files changed in the github PR explorer

---

For Admin Use:

• Added appropriate labels to PR (ex. wip, ready-for-review, docs)
• Reviewers Assigned
• Squashed all commits, uses message "Merge pull request #XYZ: [title]" (coding standards)

[colin-axner]

Great work! I left a lot of nit pick stuff and suggestions. Let me know if you have any questions.

[colin-axner]

So I think we should add a config file for this client. This would be done the same way gaiad has gaiad.toml, on each query or tx, we read from the config file for the native denom, if it is empty then we do a query for native denom and write it to the config file. This will allow client to have access to native denom without doing an additional query to the connected node. This could be used to require user to specify 100atom on a liquidity deposit despite the face the MsgAddLiquidity only takes in a big.Int for this field and then the cli could return an error if the user doesn't specify the correct denomination in their transaction.

[aayushijain23]

So I think we should add a config file for this client. This would be done the same way gaiad has gaiad.toml, on each query or tx, we read from the config file for the native denom, if it is empty then we do a query for native denom and write it to the config file. This will allow client to have access to native denom without doing an additional query to the connected node. This could be used to require user to specify 100atom on a liquidity deposit despite the face the MsgAddLiquidity only takes in a big.Int for this field and then the cli could return an error if the user doesn't specify the correct denomination in their transaction.

I like the idea of storing the native denom in a config file. Also now that the client will have access to the native denom because of the config file, we would be using that to see if the deposit amount (after parsing) has the term atom or not right? And if it doesn't, then we throw an error as you mentioned.
The only problem that I see is that although this solution works for this particular use case, there is a mismatch between the type mentioned and the value that the user gives; i.e. the field only accepts big.Int, but we are expecting the user to add the native denom to it. Is this right way to go about it?

[aayushijain23]

As discussed on Slack, will change the type from Big.Int to Coin. This will remove the mismatch between the type expected and the value that the user gives.

[fedekunze]

@aayushijain23 mind resolving issues once they are addressed?

[AdityaSripal]

This should be configurable

[colin-axner]

it is in the core code; its a parameter. The issue on the client is its useful to know what the native denom is but it is inefficient to do an extra query for it for every command especially since it doesn't change after genesis. One way of handling this is through a config file, which could be done at a later point

[fedekunze]

Let's merge this to the coinswap module PR and address the rest of the comments there