Cosmos-level governance for swingset metering+fee parameters

[JimLarson]

What is the Problem Being Solved?

Like #3665, we'd like to be able to modify the x/swingset parameters through Cosmos-level governance. Currently there are no parameters in this module, so we'd like to add max_computrons_per_block as a parameter.

Description of the Design

The entire set of x/swingset parameters should be sent to JS in the endBlockAction message by EndBlock() in golang/cosmos/x/swingset/abci.go. A reasonable default values is 8,000,000.

A second PR can have JS interpret this new field in the endBlockAction message.

Security Considerations

We need to be sure a bad value won't be able to prevent a corrective change. Fortunately, even a setting as low as zero won't prevent further action at the Cosmos level. We might consider an upper limit, though.

Test Plan

Unit tests, then we expect to try it out on the test network to tune it.

[JimLarson]

FYI, @michaelfig

[JimLarson]

In addition to the computrons-per-block parameter, we want to make parameters for charging for messages inbound to (JS-level) swingset. There will be a charge per message, plus a charge per byte, plus a charge per slot. These charges should also be subject to modification via (Cosmos-level) governance.

Also need to wire up the actual use of these charge parameters. There is one entry point in DeliverInbound of x/swingset, and another in x/vibc. Charges should be deducted from the sender's account, as identified by the ante handler (x/auth/ante/fee.go), and be sent to the x/swingset module account. Later work will handle the distribution of these fees.

Eventually, the message fee parameters will be added to the message as metadata so that they can be applied so inter-vat messages at the JS level.

[michaelfig]

Thanks, looks good. Just a different starting default:

Charges should be [...] sent to the x/swingset module account. Later work will handle the distribution of these fees.

I think for this issue to be fixed, the fees should be transferred (not minted) to x/vbank where it can distribute them using the existing time-release to x/distribution mechanism.

[michaelfig]

@warner, this is the issue I mentioned.

Along the way, we'll probably also make the user's Zoe fee purse be the same as their vbank RUN purse #3931.