Streaming proposal value for L16 and L18

[ancazamfir]

Starknet defines the context of the value in the Init and Fin content:

message ProposalInit {
    uint64  block_number   = 2;
    uint64  fork_id        = 3;
    uint32  proposal_round = 4;
}

// Finalize the Tendermint Proposal. When a validator receives this message it will presume that no
// more content for the proposal should be sent. The signature supplied with ProposalFin should be
// for the full Tendermint proposal:
// 1. height
// 2. fork_id
// 3. proposal_round
// 4. valid_round
// 5. block_hash - the validator calculates the block_hash on its own from the content stream and
//    confirms the signature with that value.
message ProposalFin {
    optional uint32 valid_round    = 1;
}

For L16 we call:

    async fn build_new_proposal(
        &self,
        height: Self::Height,
        round: Round,
        deadline: Instant,
    ) -> (
        mpsc::Receiver<Self::ProposalPart>,
        oneshot::Receiver<Self::BlockHash>,
    );

For L18:

    async fn send_known_proposal(
        &self,
        block_hash: Self::BlockHash,
    ) -> mpsc::Sender<Self::ProposalPart>;

This discussion is to clarify the following:

Let's assume

• some proposer p streamed v at round vr.
• v was received by the current proposer q that also saw a polka for v such that q set v as valid (executed L42-L43).
• some validators have received v at vr and have stored (v, vr)
• q will proposes v so it calls send_known_proposal()
• a non-proposer that also saw v in vr should be able to tell early in the streaming process that this is a "resend" so it can ignore it. Shouldn't Init include valid_round in this case? This should be known as value builder had previously stored the round of the value (vr) along with v. What was proposal_round at vr is now valid_round at r.
• looks like we are missing r (aka proposal_round) in send_known_proposal() API, ie the call should be:

host.send_known_proposal(block_hash, proposal_round).await;

• we should clarify if proposal_round in this call goes in Init or Fin and if the stored vr goes in Fin or Init
• does the spec include vr in Fin because of streaming issues? e.g. a validator v that has two parallel streams, one started by p and one by q with same Init content? cc @romac

[cason]

Jumping super late here, the valid round should be send at the beginning, namely on the Init message.