blockstore: relax backwards chained merkle root check for upgrades

[AshwinSekar]

Problem

If a validator upgrades from a version that does not contain the MerkleRootMeta column in blockstore in the middle of receiving shreds for a slot we cannot assume that the MerkleRootMeta exists.

Specifically, if a coding shred is received from FEC set N before the upgrade, when the first shred from FEC set N+1 is received post upgrade, we will perform the backwards chained merkle root check.
This check assumes that both the erasure meta and merkle root meta exists for FEC set N.

Summary of Changes

Relax this check to warn and succeed if the MerkleRootMeta is missing for the previous FEC set.
The corresponding forward check already handles this case correctly.

Note: the actual results of this check are not processed until the chained_merkle_conflict_duplicate_proofs feature is activated. This feature will only be activated several epochs after the cluster has upgraded ensuring that there are no missing MerkleRootMetas

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 82.1%. Comparing base (f291ca4) to head (f1f9dbe).
Report is 2 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff            @@
##           master    #1163     +/-   ##
=========================================
- Coverage    82.1%    82.1%   -0.1%     
=========================================
  Files         886      886             
  Lines      236392   236450     +58     
=========================================
- Hits       194274   194264     -10     
- Misses      42118    42186     +68     

[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.