Auto-provision smart wallet

[mhofman]

closes: #8558

Description

This change implements smart wallet auto-provisioning by:

• Checking if a smart wallet is already provisioned in vstorage during admission checks
• Charging a new beans based fee if not
• Generating a provision action when processing the smart wallet message based on whether the smart wallet is provisioned already or not

It does not mark whether a smart wallet provision is pending, and as such may result in provision beans fees being charged multiple times if smart wallet messages are submitted and included in new blocks before the provision message is executed by swingset.

This PR includes some necessary changes to the upgrade handler:

• Generalizing the swingset parameters logic to always add new parameters using their default value in the upgrade handler

Security Considerations

The provision step in swingset does not change and still provides a nominal amount of IST during provisioning, for each provision message handled. As such the beans amount charged for auto-provisioning a wallet should be higher than the nominal amount transferred from the provision pool.

Scaling Considerations

None

Documentation Considerations

TBD

Testing Considerations

TBD

Upgrade Considerations

Requires a new chain software consensus upgrade.
Added required logic to the upgrade handler for the new fee.

[JimLarson]

High-level comments:

Impressive plumbing to get that all wired through!

I'm a little concerned about the additional complexity for trying to suppress duplicate auto-provisioning within the same transaction. We're already resigned to having duplicate auto-provision requests in different blocks while the first request is still queued, so maybe that's an acceptable way to handle the now-impossible case of multiple wallet messages in a single transaction? It would be great if we could drop the customization of sdk.Context. Doing so would require both the ante handler and the msg server to check vstorage for the existence of the wallet, but I don't think that's prohibitive.

[mhofman]

It would be great if we could drop the customization of sdk.Context. Doing so would require both the ante handler and the msg server to check vstorage for the existence of the wallet, but I don't think that's prohibitive.

It felt wrong for the msg server to assume all unprovisioned smart wallet messages allowed by the ante handler were eligible for auto provisioning, seeing how decoupled they are, but I suppose that's a fair assumption to make. I do agree it would simplify the logic, and maybe with sufficient comments in both directions it'd be acceptable.

[mhofman]

@JimLarson

I removed the ctx logic. In hindsight, it's much better because it wouldn't be needed anyway if/when we implement marking of pending provisions.

We could potentially re-use the egress marking of explicit provision to implement this marking now.

[mhofman]

Addressed feedback, then fixed-up: cf6f4d2...cdbaa77

[JimLarson]

Much simpler now! But a few remaining cleanups. Should be quick.

[mhofman]

Rolled into #8623