Can we delete this now? Looks like it's not going to be used.

Also, I think we should stick with MaxBytes, not MaxDataBytes.

MaxBytes provides a clear limit on the total size of a block that requires no additional calculation if you want to use it to bound resource usage, and there has been considerable discussions about optimizing tendermint around 1MB blocks. Regardless, we need some maximum on the size of a block so we can avoid unmarshalling blocks that are too big during the consensus, and it seems more straightforward to provide a single fixed number for this rather than a computation of "MaxDataBytes + everything else you need to make room for (signatures, evidence, header)". MaxBytes provides a simple bound so we can always say "blocks are less than X MB".

Having both MaxBytes and MaxDataBytes feels like unnecessary complexity. I don't think it's particularly surprising for MaxBytes to imply the maximum size of the entire block (not just txs), one just has to know that a block includes header, txs, evidence, votes. For more fine grained control over the txs included in the block, we have the MaxGas. In practice, I would expect the MaxGas to do most of the tx throttling, and the MaxBytes to just serve as an upper bound on the total size. Applications can use MaxGas as a MaxDataBytes by just taking the gas for every tx to be its size in bytes.

This reasoning should be included in ADR-020

I think this can be closed - transferred the rationale to ADR-020 in #3116