v1.18: replay: only vote on blocks with >= 32 data shreds in last fec set (backport of #1002)

[mergify]

Continued from solana-labs#35024

Problem

In order to ensure that the last erasure batch was sufficiently propagated through turbine, we verify that 32+ shreds are received from turbine or repair.

Summary of Changes

#639 pads the last erasure batch with empty data shreds such that there are at least >= 32 data shreds.
Once a block has finished replay, we can check if the last FEC set is full by seeing if there are >= 32 data shreds with the same merkle root. This implies that at least 32 data or coding shreds were received through turbine or repair.

---

This is an automatic backport of pull request #1002 done by [Mergify](https://mergify.com).

[mergify]

Cherry-pick of 8c67696 has failed:

On branch mergify/bp/v1.18/pr-1002
Your branch is up to date with 'origin/v1.18'.

You are currently cherry-picking commit 8c67696346.
  (fix conflicts and run "git cherry-pick --continue")
  (use "git cherry-pick --skip" to skip this patch)
  (use "git cherry-pick --abort" to cancel the cherry-pick operation)

Changes to be committed:
	modified:   ledger/src/blockstore.rs
	modified:   ledger/src/blockstore_db.rs

Unmerged paths:
  (use "git add <file>..." to mark resolution)
	both modified:   core/src/replay_stage.rs
	both modified:   ledger/src/blockstore_processor.rs
	both modified:   sdk/src/feature_set.rs

To fix up this pull request, you can check it out locally. See documentation: https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/reviewing-changes-in-pull-requests/checking-out-pull-requests-locally

[AshwinSekar]

This backport checks if the last FEC set of a replayed block is "full" (sufficient # of shreds to have undergone meaningful duplicate block prevention checks).

If it is not "full", or if blockstore.is_last_fec_set_full returns an error, we log and report metrics. Once the feature flag is turned on we will also mark the block as dead.

I believe this change to be unintrusive when the feature flag is off, and will allow us to begin collecting metrics on mainnet 1.18. This will give us the confidence to eventually turn on the feature flag, once the remaining duplicate block prevention feature flags in the queue are turned on.