Favor Marshal/Unmarshal BinaryBare over Length-Prefixing

[alexanderbez]

Summary

Nearly throughout the entire SDK, we use length-prefixing during serialization through a codec. There are a handful of places where this makes sense (e.g. result.Data), but a majority of the business logic does not work with or handle streams, so it makes no sense to length-prefix. Replace all occurrences with non-length-prefix variants.

/cc @aaronc

---

For Admin Use

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

[aaronc]

@alexanderbez what are the cases where it makes sense in result.Data?

[alexanderbez]

@alexanderbez what are the cases where it makes sense in result.Data?

https://github.com/cosmos/cosmos-sdk/blob/master/baseapp/baseapp.go#L611-L617

Example:

https://github.com/cosmos/cosmos-sdk/blob/master/x/staking/handler.go#L232-L247

These are the only cases that need to be length-prefixed.

[aaronc]

Why not simplify things by just doing the length-prefixing in runMsgs? The less special context that people writing handlers need to know about, the better. IMHO we could get a way with a single MarshalBinary or Marshal method.

[alexanderbez]

Why not simplify things by just doing the length-prefixing in runMsgs? The less special context that people writing handlers need to know about, the better. IMHO we could get a way with a single MarshalBinary or Marshal method.

We can -- I'm just letting you know the edge cases.