v1.18: retains chained Merkle root across leader slots (backport of #1057)

[mergify]

Problem

Looking up Merkle root of the last erasure batch for the parent block can fail if the slot meta are not yet available in blockstore.
When a leader generates blocks for its consecutive leader slots, instead of using blockstore, it can retain chained Merkle root across its leader slots.

Summary of Changes

Retain chained Merkle roots across leader slots.

---

This is an automatic backport of pull request #1057 done by Mergify.

[codecov-commenter]

Codecov Report

Attention: Patch coverage is 94.87179% with 6 lines in your changes are missing coverage. Please review.

Project coverage is 81.6%. Comparing base (c8e6fd0) to head (5ab1b32).

Additional details and impacted files

@@            Coverage Diff            @@
##            v1.18    #1182     +/-   ##
=========================================
- Coverage    81.6%    81.6%   -0.1%     
=========================================
  Files         827      827             
  Lines      225352   225332     -20     
=========================================
- Hits       184011   183994     -17     
+ Misses      41341    41338      -3     

[behzadnouri]

@sakridge @CriesofCarrots @t-nelson

This change has been pending for more than 2 weeks.

[behzadnouri]

@sakridge @CriesofCarrots @t-nelson
This has been pending for 1 month now.
This is part of the chained merkle shreds and we definitely want this change so that to monitor err_unknown_chained_merkle_root before rolling out chained merkle shreds.

[CriesofCarrots]

This has been pending for 1 month now.

Yes, pending without any context posted on the PR.
As Trent mentioned, this diff is quite difficult to parse. It also seems to do a lot more than adjust err_unknown_chained_merkle_root; perhaps multiple commits in the original PR would have made it easier to distinguish new behavior from refactoring. I don't feel comfortable rubber-stamping atm.

[behzadnouri]

This has been pending for 1 month now.

Yes, pending without any context posted on the PR. As Trent mentioned, this diff is quite difficult to parse. It also seems to do a lot more than adjust err_unknown_chained_merkle_root; perhaps multiple commits in the original PR would have made it easier to distinguish new behavior from refactoring. I don't feel comfortable rubber-stamping atm.

@CriesofCarrots if you have specific questions about the code and change please ask.
ignoring the code review and pings for one month is not going to help with that.
after all, you have been forcing yourself to be the code reviewer on the code you don't have context on.

[t-nelson]

review coordinated offline. i'm ok with these changes now