makes last erasure batch size >= 64 shreds

[behzadnouri]

Problem

wider retransmitter set for last erasure batch.

Summary of Changes

makes last erasure batch size >= 64 shreds

[behzadnouri]

The test is already flaky: #32863 but fails a lot more with this code.
I have to ignore it for now for CI to pass, since this code is not the culprit anyways.

[codecov]

Codecov Report

Merging #34330 (6043a51) into master (8c6239c) will decrease coverage by 0.1%.
The diff coverage is 88.4%.

Additional details and impacted files

@@            Coverage Diff            @@
##           master   #34330     +/-   ##
=========================================
- Coverage    82.0%    82.0%   -0.1%     
=========================================
  Files         819      819             
  Lines      220598   220625     +27     
=========================================
+ Hits       180898   180914     +16     
- Misses      39700    39711     +11     

[AshwinSekar]

how expensive is it to pad with 32 - d data shreds instead?
just curious because it could make verification simpler (compare fec set of last_shred_in_slot and last_shred_in_slot - 31) vs counting coding shreds
also we then have an inherent tracker in max_tick_height. otherwise we'll have to add a tracker to revisit when enough coding shreds have been received.

not saying it can't be done, but introduces some more complexity on the verification side.

[behzadnouri]

how expensive is it to pad with 32 - d data shreds instead?
just curious because it could make verification simpler (compare fec set of last_shred_in_slot and last_shred_in_slot - 31) vs counting coding shreds

From erasure coding perspective, it would be pretty wasteful to add more empty data shreds instead of coding shreds.
Lets see how the verification code looks like and we can revise this if needed.

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