Maximum tx size enforcement does not account for full transaction encoding

[mzabaluev]

Summary of Bug

When splitting messages into batches to form transactions, the max_tx_size limit only accounts for message content. It's still possible that the full TxRaw encoded message exceeds this limit.

This raises some questions:

• Does this configuration parameter mean the full transaction size including the signatures and AuthInfo data, as encoded in protobuf? Or is there any other way to calculate the tx size that could be more useful to relayer operators, e.g. for purposes of limiting fees?
• How likely does this discrepancy matter in practical use, to decide on the priority of fixing this?
• How important it is to pack the messages exhaustively up to the tx size limit? For example, if the relayer bumps one message off a transaction to the next batch due to using some size estimation heuristics, while in perfect implementation the message could still fit within the tx, how costly this miscalculation could be?

Version

1.0.0-rc.2

Steps to Reproduce

Not observed specifically for this cause, but see #2422 for possible symptoms.

Acceptance Criteria

• There is a documented meaning for the max_tx_size chain config parameter, and it is correctly enforced.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate milestone (priority) applied
• Appropriate contributors tagged
• Contributor assigned/self-assigned