improve stake account ux

[2501babe]

Problem

figuring out exactly what state a stake account is in is complex and error-prone:

1. determining if a stake account is active, activating, deactivating, or inactive is typically done via a combination of matching on StakeStateV2 enum variants and manually comparing Delegation.activation_epoch and Delegation.deactivation_epoch to Clock.epoch and u64::MAX
2. a common mistake (that i have made myself) is doing the steps in 1 and looking at Delegation.stake. this is not correct: it fails to consider partial activation or deactivation in the case of warmup or cooldown, and the "delegated" amount is left intact for an inactive account that was previously active
3. the true way to determine stake account state is to call stake_activating_and_deactivating() on Delegation with Clock and StakeHistory. this returns StakeActivationStatus, which is just a type alias for StakeHistoryEntry, which is a triple of effective, activating, and deactivating. this can be used to determine the true state of a stake account, but:
   • it requires end-users to compare values by hand
   • you still need to match on StakeStateV2 for uninitialized and initialized accounts
   • distinguishing between deactivating and partially deactivated also requires looking at Delegation.stake

Solution

add a new enum StakeAccountStatus or similar, with variants: uninitialized, activating, partially active, fully active, deactivating, partially deactivated, fully inactive. abstract over the distinction between an initialized account and a fully deactivated account. carry StakeActivationStatus as a value on variants where it makes sense. have whatever boolean-return helpers are convenient. possibly include helpers for determining things about minimum delegation and excess undelegated lamports

most of the required logic is actually already implemented: its just part of MergeKind, an internal stake program helper for Merge (also now used by MoveStake and MoveLamports because it is so convenient, but not Split, Withdraw, or anything else). we should abstract this out, move it into sdk, and use it across all relevant stake program process functions and the stake pools to replace the ad hoc way we do all this now

until very recently the hard requirement on StakeHistory made this kind of accounting a huge burden for stake operations that didnt truly "need" it. but last week (note: this issue was originally opened in february) we activated get_sysvar on mainnet, which enables StakeHistory access without:

• needing to include the account in the accounts list
• needing to deserialize it into an AccountInfo
• needing to store a 16kb vec on the heap

with the ability to get individual stake history entries via syscall (and only one is needed if there is no warmup/cooldown), we can implement a one true way of doing this now

(this is the new home of anza-xyz/solana-sdk#61)

[2501babe]

the other things i was thinking when i write this are:

• ideally this would be zero-copy. the stake program uses compute units now and the biggest predictor of how many it uses is how many times it needs to deserialize stake accounts. i dont know offhand if stake account data is aligned or not (to be able to use bytemuck) but i suspect it is, since Meta, Stake, and Delegation are entirely u64s and pubkeys
• ideally we design this in such a way that pinnochio is happy with it and if/when we port the stake program we dont need to change it. i dont know what special rules pinnochio has about structs that are meant to correspond to account data (cc @febo)
• ideally we design this such that if/when we implement multistake, we can add in multistake support with backwards and forwards compat. ie, an old version of this should gracefully be able to do operations on the main stake account of a multistake (ie one that is longer than 200 bytes). and a new version of this should gracefully handle accounts that have not been upgraded

[febo]

An alternative approach to bytemuck is to define a zero-copy trait to represent the accounts data, similarly to p-token. It is relatively simple to avoid alignment issues and maintain backwards compatibility if everything is aligned to 1 – there is a bit of conversion needed when working with enum and u64 values, but the overhead is minimal and smaller than bytemuck. Ideally we should have our own "codec" package to handle this (cc: @buffalojoec), but in the meantime a "custom" trait works well.

Pinocchio is unopinionated regarding how the account data is structure, so any approach would work fine.

[buffalojoec]

An alternative approach to bytemuck is to define a zero-copy trait to represent the accounts data, similarly to p-token. It is relatively simple to avoid alignment issues and maintain backwards compatibility if everything is aligned to 1 – there is a bit of conversion needed when working with enum and u64 values, but the overhead is minimal and smaller than bytemuck. Ideally we should have our own "codec" package to handle this (cc: @buffalojoec), but in the meantime a "custom" trait works well.

You mean this @febo?
https://github.com/buffalojoec/spl-zero-copy