Remove duplicate vote transaction

[carllin]

Problem

vote transaction is duplicated, vote crate is unnecessary

Summary of Changes

Delete vote crate, move everything into vote-program

Fixes #

[mergify]

If this PR represents a change to the public RPC API:

1. Make sure it includes a complementary update to rpc-client/ (example)
2. Open a follow-up PR to update the JavaScript client @solana/web3.js (example)

Thank you for keeping the RPC clients in sync with the server API @carllin.

[mergify]

The Firedancer team maintains a line-for-line reimplementation of the
native programs, and until native programs are moved to BPF, those
implementations must exactly match their Agave counterparts.
If this PR represents a change to a native program implementation (not
tests), please include a reviewer from the Firedancer team. And please
keep refactors to a minimum.

[carllin]

Other program/vote/VoteTransaction has CompactVoteStateUpdate as third enum

[ksn6]

(likely need to include the serde macro as well for TowerSync)

[AshwinSekar]

generally in support of this change, however it might break downstream so I would imagine we need to deprecate VoteTransaction first

[AshwinSekar]

nice ya in support of this change.
This is a public crate though do we have to go through the process of deprecating it for a version and then deleting it in the next? or can we just break it

[carllin]

generally in support of this change, however it might break downstream so I would imagine we need to deprecate VoteTransaction first

Yup need to deprecate him, how does one go about doing that @joncinque @buffalojoec

[joncinque]

solana-vote shouldn't be included as part of the semver policy, so you should be good to just remove it. https://crates.io/crates/solana-vote/reverse_dependencies shows only solana- dependents

[mergify]

The Firedancer team maintains a line-for-line reimplementation of the
native programs, and until native programs are moved to BPF, those
implementations must exactly match their Agave counterparts.
If this PR represents a change to a native program implementation (not
tests), please include a reviewer from the Firedancer team. And please
keep refactors to a minimum.

[jstarry]

Lol this was fun to look into the history for:

• Refactor: move simple vote parsing to runtime solana-labs/solana#22537 moved runtime related vote code from solana-vote-program into solana-runtime
• Add feature gate for new vote instruction and plumb through replay solana-labs/solana#21683 added some of that code back into solana-vote-program due to a merge conflict and I guess no one noticed
• Split vote related code from runtime to its own crate solana-labs/solana#32882 moved runtime related vote code from solana-runtime to solana-vote
• and now this PR is finally removing the duplicated code from 21683 and moving solana-vote code back into solana-vote-program

In my mind, solana-vote should still exist to hold code for runtime related vote code. solana-vote-program should be used for clients constructing vote instructions and for clients deserializing onchain vote state. The runtime code doesn't belong there.

If we look at the modules you are moving into solana-vote-program, we have the vote_account module which is used for the stakes cache and the vote_parser module which is used by the runtime (banking stage and replay stage) to identify vote transactions to send to ClusterInfoVoteListener for consensus tracking. I'm also making a vote_state_view module for the stakes cache so that we no longer need to allocate memory to hold vote state info (we should access fields directly from the backing account data vec). All of this is only used by the runtime so it doesn't need to be put in the solana-vote-program crate that downstream users will use.

This PR should remove the duplicated VoteTransaction but leave solana-vote alone please!

[jstarry]

Sorry to clarify, I don't actually have any special love for the solana-vote crate, I just don't want runtime code in the solana-vote-program crate. If you kill solana-vote, move that code back into solana-runtime rather than in a client facing solana-vote-program crate or whatever solana-program/vote will be

[jstarry]

Oh I also just realized we have solana-vote-interface too which is actually the thing that has the vote instruction and state structs. solana-vote-program should just be the vote processing code then. And then solana-runtime or solana-vote should have the runtime related vote code.

[carllin]

vote_parser relies on VoteTransaction, so seems like we should pull VoteTransaction out of solana-program into solana-vote?

[jstarry]

Yeah it should live in solana-vote