Treat proposal and block parts explicitly in the spec

[josef-widder]

The arXiv paper just talks about Propose message that contains the block, while in the implementation, there is a Propose message that only contains the hash of the block and there are block parts gossiped around. It would be great to capture the implementation more closely in the new PBTS spec.

Originally posted by @josef-widder in tendermint/spec#369 (comment)

[williambanfield]

From the perspective of the Tendermint codebase, I understand why describing the distinction is important, but from the perspective of the specification of the PBTS algorithm in relationship to the original arXiv paper, I'm not sure it's that meaningful. The number of 'messages' that a proposal is split across feels like a bit of an implementation concern to me, but perhaps there's something I'm not seeing.

[josef-widder]

It is definitely an implementation concern.

I still think we should at least have a remark in the specification that a propose message in the spec is implemented via block parts etc. I don't think we need the remark to be super precise. I just want to have it mentioned. (After all, this point raised quite some discussion regarding when timely should be implemented in the implementation.)

[cason]

The current state, that I should push soon: MSGDELAY applies to regular consensus messages, by which it is meant messages that have essentially constant size. That is, it applies to Proposal messages, which should have a fixed size, but not for blocks, whatever way they are disseminated.

[cason]

This probably should be make clear, both in the English and in the TLA+ spec (@Kukovec ). We probably don't need explicitly to distinct a Proposal from BlockPart messages, but maybe make it clear that a process can receive a value without receiving a Proposal.