target current leader with votes

[bw-solana]

Problem

See #1851 for some background
As part of sending votes, we try and identify the current leader we should send to. We currently use our best understanding of the current slot (slot N) and send to leader(s) building the next 2 slots (slots N+1 and N+2). Often N+1 and N+2 are built by the same leader and will be de-duped.

The potential issue occurs when leaders are building the last slot of their 4 slot quartet. If nodes have a fresh view of things, they may observe the current slot being build (N) as the latest, but they will send their vote for N-1 to the next leader that is going to build N+1. It would be good to also try and land this vote in N. This likely explains why we often see the first leader slot overpacked with votes (and conversely, the last slot being lightly packed).

Summary of Changes

Change targeting to include the current highest slot as well. This will result in 1 additional vote transaction being sent out per node per leader slot quartet. I.e. an increase of 20% from 5 to 6 votes per quartet.

Current Slot	Old Target Slots	Old Target Leader(s)	New Target Slots	New Target Leader(s)
0	1,2	Leader A	0,1,2	Leader A
1	2,3	Leader A	1,2,3	Leader A
2	3,4	Leader A,B	2,3,4	Leader A,B
3	4,5	Leader B	3,4,5	Leader A,B
4	5,6	Leader B	4,5,6	Leader B
5	6,7	Leader B	5,6,7	Leader B
6	7,8	Leader B,C	6,7,8	Leader B,C
7	8,9	Leader C	7,8,9	Leader B,C

[jstarry]

I'm happy to ship this as is but would also like to fix up a few things (I can take care of them if you want):

1. After resetting poh to a new bank, we start the PohRecorder::tick_height field at the last tick of the new bank. So fn PohRecorder::slot_for_tick_height will incorrectly return the current slot as N - 1 until we record the first tick.
2. The upcoming_leader_tpu_vote_sockets method has a fanout_slots parameter which should be updated since now we are fanning out to 3 slots rather than 2.

[bw-solana]

I'm happy to ship this as is but would also like to fix up a few things (I can take care of them if you want):

1. After resetting poh to a new bank, we start the PohRecorder::tick_height field at the last tick of the new bank. So fn PohRecorder::slot_for_tick_height will incorrectly return the current slot as N - 1 until we record the first tick.
2. The upcoming_leader_tpu_vote_sockets method has a fanout_slots parameter which should be updated since now we are fanning out to 3 slots rather than 2.

Added a commit address (2).

(1) feels like the more important but messier one. Happy to have you take that one if you have some ideas.

[AshwinSekar]

Love it, wondering if we should go further:

• [N - fanout_slots, N + fanout_slots] to cover cases where our poh is ahead
• incorporate the slot being voted on, fanout from the poh slot for most cases, and fanout from the vote slot for the weirder forking cases.

Hard to estimate if the extra spam is worth improving latency in these corner cases

[bw-solana]

Love it, wondering if we should go further:

• [N - fanout_slots, N + fanout_slots] to cover cases where our poh is ahead
• incorporate the slot being voted on, fanout from the poh slot for most cases, and fanout from the vote slot for the weirder forking cases.

Hard to estimate if the extra spam is worth improving latency in these corner cases

yeah, this is interesting.. I can do some more analysis on targeting success and follow-up in a future PR (if it makes sense)