blockstore: always send a coding shred for chained merkle root conflicts

[AshwinSekar]

Problem

#835 has a chance to send a chained merkle root conflict duplicate proof consisting of 2 data shreds.
With 2 data shreds we cannot verify that they are from adjacent FEC sets. We require that the shred from the lower FEC set be a coding shred.

Summary of Changes

• Modify the backwards check to always send the coding shred from lower FEC set. We know this is available because there must be an erasure meta.
• Modify tests to check the upgrade scenario, where the first received coding shred index is not reliable (skip the check in this case).

This ensures that we always send a coding shred for the lower FEC set, meaning the gossip handler can verify that duplicate proofs are for adjacent FEC sets.
Without this verification an attacker can arbitrarily pick non adjacent FEC sets to "prove" that every block is duplicate

Contributes to solana-labs#34897

[AshwinSekar]

This is safe because self.previous_erasure_set() on line 1896 must have found an ErasureMeta for prev_erasure_set in order to reach here.

[behzadnouri]

Shouldn't fn previous_erasure_set actually return that ErasureMeta instead of looking it up again here?

[AshwinSekar]

yeah good point, I didn't do this last time because we only needed the merkle root.
Updated it to return the meta as well.

[AshwinSekar]

We enter this if either:

• Blockstore cleanup has caught up to root and prev_shred has been cleaned up
• prev_erasure_meta was inserted with an older version and prev_erasure_meta.first_received_coding_shred_index() points to shred 0 which we do not have.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.7%. Comparing base (097aa8e) to head (1f28b82).

Additional details and impacted files

@@            Coverage Diff            @@
##           master    #1353     +/-   ##
=========================================
- Coverage    82.7%    82.7%   -0.1%     
=========================================
  Files         876      876             
  Lines      371180   371185      +5     
=========================================
  Hits       307275   307275             
- Misses      63905    63910      +5     

[mergify]

Backports to the beta branch are to be avoided unless absolutely necessary for fixing bugs, security issues, and perf regressions. Changes intended for backport should be structured such that a minimum effective diff can be committed separately from any refactoring, plumbing, cleanup, etc that are not strictly necessary to achieve the goal. Any of the latter should go only into master and ride the normal stabilization schedule. Exceptions include CI/metrics changes, CLI improvements and documentation updates on a case by case basis.