Use VoteAccount::node_pubkey()

[brooksprumo]

The original intent of this PR changed. See the discussion (and #26207 (comment) for more info).

Problem

Original:

Clippy was warning about temporary with significant drop in match scrutinee for a bunch of uses of VoteAccounts::vote_state(). These locks are all reader locks, and there will never be another writer (since the one was within a Once), so the clippy warnings are safe to ignore.

See #26207 (comment) for more info.

Related to #24836

Actual:

No problem, just an opportunity to refactor 😐

Summary of Changes

Use VoteAccount::node_pubkey() when possible.

[brooksprumo]

@buffalu Can't add you to the reviewer's list, but want to make sure you're in the loop.

[buffalu]

nice find, thanks clippy gods

[behzadnouri]

This does not seem to be necessary.

The only place that self.0.vote_state is write locked is here:
https://github.com/solana-labs/solana/blob/2efdb965d/runtime/src/vote_account.rs#L82-L89
which is done once and only once the very first time anyone touches VoteAccount::vote_state.
It does not have a lock contention there because it is wrapped in Once::call_once and there is no other lock reference there yet at that point.

All other references are shared-lock, so they can't cause any lock contention.

So, this is a false positive warning, and no need to add manual drops or additional .clone overhead.
Lets just ignore it with #[allow(clippy::...)]

[brooksprumo]

This does not seem to be necessary.

Thanks for the explanation. I agree.

Lets just ignore it with #[allow(clippy::...)]

I tried, but since the lints are in a version newer than 1.60.0, CI checks fails. So this PR has morphed into a tiny refactor to call VoteAccount::node_pubkey().

[mvines]

This lint occurs all over the code base with recent nightlies, and it seems questionable and/or too aggressive.
In #25489 I globally suppressed it here. That PR is blocked on a the debug of a couple test failures though