Fix Turbine making Port based decisions

[sagar-solana]

Problem

Turbine chooses whether or not to forward a packet to neighbors and children or just children based on which port the packet arrived on. Turbine also drops any packets that arrive on the repair port.

This port based filtering is a problem because it can easily be spoofed and cause selective propagation of packets through a cluster

Summary of Changes

A Validator will now always perform a "wide"(to neighbors and children) retransmit if it was on the critical path for a packet.

Validators can easily check if they are "on the critical path" for a given packet (since the Turbine tree is shuffled per packet) by looking at their index after the shuffle. If their Index is a multiple of the Turbine Fanout, that means they must be on the critical path.

First of many partial fixes for #6672

[sagar-solana]

Pending a testnet run + some more reasoning through it to make sure this doesn't break anything.

Pull request has been modified.

[sagar-solana]

Oh awesome, looks like it broke the retransmit bench because Turbine is more secure now and refuses to propagate packets that are not in the critical path.

[codecov]

Codecov Report

Merging #7774 into master will decrease coverage by 0.2%.
The diff coverage is 0%.

@@           Coverage Diff            @@
##           master   #7774     +/-   ##
========================================
- Coverage    81.8%   81.6%   -0.3%     
========================================
  Files         238     241      +3     
  Lines       50993   50973     -20     
========================================
- Hits        41730   41604    -126     
- Misses       9263    9369    +106

[sagar-solana]

This appears to cause some odd behavior on testnet. Need to figure out why. UDP traffic is comparable but I think there's a corner case or something that's preventing data from reaching everyone properly. Going to hold off on merging this till I can figure out if there's a bug in the logic.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[garious]

@sagar-solana, I see @aeyakovenko approved this PR. Still working on it or ready to land?

[sagar-solana]

@garious It's not working as expected and I haven't been able to identify why. I can take the PR down and re-upload it when it works if you prefer that.

[garious]

Nah, you can leave it. Just needed to know its status. Thanks!

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[stale]

This stale pull request has been automatically closed. Thank you for your contributions.