IF: Verify net messages for validity

[heifner]

Depends on #1881 and #1657.

• Verify hs_vote_message finalizer is valid one to use. Verify public key is part of the sig. (This should be done once in qc_chain.)
• Verify quorum_certificate_message active_finalizers public keys are part of the sig. (This should be done once in qc_chain.)
• Verify length of quorum_certificate_message active_finalizers does not exceed maximum size calculated based on maximum number of allowed finalizers (2^16) and the constraint that each finalizer has a description that does not exceed 256 bytes.

[arhag]

P = proposal message (which is extracted from the signed_block message with the QC justification stored in the block extension)
V = vote message (new message type to support IF)

Three categories of message validation failure:

1. Immediately disconnect peer that sent the message:

• Proposal has slot/view number that violates monotonicity (or other objectively verifiable constraints). (P2)
• Proposal by leader not allowed to propose for that slot/view number. (P4)
• Validate proposal signed by key corresponding to claimed proposer. (P5)
• Any other self-consistency validations of the block header data. (P6) [Could also blame proposer at this point but we don't need to have a mechanism to punish the proposer implemented.]
• Block header references (IF) ancestor block as last block with QC which is different than the one referenced in the previous block, yet the block extension does not contain a QC for that referenced block. (P7) [Cannot blame the proposer for this failure though.]
• QC in block extension is valid with respect to the referenced IF ancestor block. This means computing the aggregate public key from the bitset included with the QC in the block extension and using it to validate the QC signature. (P8) [Cannot blame the proposer for this failure though.]
• Vote message uses public key that is not in the finalizer set for the referenced proposal. (V2)
• Vote message signature is invalid. (V3)

2. Track by updating per-connection abuse detector (which may eventually disconnect peer):

• Unlinkable proposal. (P1)
• Proposal is for a slot/view number that is significantly in the future relative to what is expected from the current wall-clock time. (P3)
• Received vote for unknown proposal. (V0)

3. Drop message and do nothing else other than maybe logging:

• Redundant proposal. (P0) [May want to revisit if it should be recategorized to 2.]
• Redundant vote. (V1) [May want to revisit if it should be recategorized to 2.]