state-sync cannot restore payloads larger than 64MB

[mhofman]

Describe the bug

cosmos-sdk hardcodes a maximum payload size of 64MB used when restoring from a state-sync snapshot.

Unfortunately mainnet has an artifact larger than that (the boostrap vat's first transcript span), resulting in the inability to restore from state-sync.

The error is pretty cryptic, simply:

ERR failed to restore snapshot err="extension swingset restore: short buffer"
ERR State sync failed err="state sync aborted" module=statesync

There is no stack trace available being a built-in error, but it's returned from the protobuf io package

To Reproduce

Try to restore from state-sync using agoric-upgrade-11 software

Expected behavior

Restore from state-sync successful.

Platform Environment

agoric-upgrade-11

Additional context

I have verified that locally patching /go/pkg/mod/github.com/agoric-labs/cosmos-sdk@v0.45.11-alpha.agoric.3/snapshots/manager.go to increase the value allows a state-sync restore to succeed.

While this is safe to patch locally as it doesn't affect consensus, releasing as a hotfix is more difficult because of the risk of cosmos package version sneaking into JS errors which are in consensus.

[mhofman]

We need to pick a number for a higher limit. For reference, we have similar size prefixed constraints in our netstring implementation between Swingset and xsnap, and the limit is 1GB - 1 (9 numerical digits). I would want at least 256 MB in case we do end up with larger artifacts down the road for some reason. The upper constraint is mainly a memory allocation one I believe.

Testing plan: extend the cosmos-sdk unit tests of state-sync to attempt the restore of 2 payloads, one just below the increased limit, one right over.

[mhofman]

It looks like protobuf only allocates up to the needed length so it should be safe to have this number at a higher limit.

[mhofman]

Reopening until cosmos-sdk is updated, assigning to @JimLarson

[mhofman]

Closing in favor of #8223 which will pick up the new Cosmos SDK tag.

[mhofman]

We cannot wait until #8223 after all, so re-opening to track update of cosmos-sdk