Create Provenance-specific config file.

[SpicyLemon]

Summary

Create a new config file to house any provenance-specific configuration.

Problem Definition

We currently have a --testnet flag that would be easier to manage if it were an option in a config file. Also, with #952, there are some streaming configuration pieces that we would also want in that file.

While it would technically be possible to put them in the app.toml or config.toml files, any such entries would be removed if the provenanced config set, pack or unpack commands are used. That's because the writing of those files uses a template that's outside of our control, and doesn't have those custom additional fields.

Proposal

1. Create our own configuration struct.
2. Create our own configuration file template.
3. Add this new config file and struct to the existing config reading/writing. That includes the config commands and packing/unpacking the config.
4. Make sure that the testnet config field is looked for early enough to be usable everywhere that currently looks for the --testnet flag.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned

[SpicyLemon]

PR #952 will be adding the stuff to pay attention to the streaming configuration fields. The app/streaming/README.md file should have the information needed to create that section in our own file.

Once that PR is merged:

1. The provenanced config get, and changed commands will not know about the new fields (even if configured in one of the files).
2. Using the provenanced config set, pack, and unpack commands will destroy any previously defined streaming configuration.

[SpicyLemon]

As another aspect of this, we might think about defining a custom config file (e.g. custom.toml) that is never automatically written to, but is looked for and loaded (even if the config is packed). That would provide a safe place for any sort of custom configuration that isn't included in any of the config templates. I know that there are some other secret config options available that aren't part of any templates, and are expected to just be additions to the app.toml or config.toml file.

I'm tempted to suggest that we just load any .toml files that are in the config directory, but that seems a bit unsafe. Plus, currently, if there's a packed config file, the .toml files are ignored. By limiting it to a single file, that ignoring is easier to bypass.

[SpicyLemon]

I created #989 for allowing a custom.toml that isn't managed by the provenanced config commands.

[SpicyLemon]

#1067 brings a couple more configurable pieces: fee denom and staking denom.