staking-pool: unstake_all will lock up the tokens that are already available to withdraw

[nagisa]

Consider a situation like this:

1. Stake 5 near with some pool;
2. Unstake 1 near, and wait for the token to be released, so that it is available to withdraw;

At this point calling the unstake_all method will move the 1 token that was available to withdraw back to the pending release state. Upon brief reading of the code around this area

core-contracts/staking-pool/src/internal.rs

Lines 154 to 157 in dad58eb

	account.stake_shares -= num_shares;
	account.unstaked += receive_amount;
	account.unstaked_available_epoch_height = env::epoch_height() + NUM_EPOCHS_TO_UNLOCK;
	self.internal_save_account(&account_id, &account);

it seems like the behaviour would be the same for the regular unstake method with the amount too.

I’d argue that this behaviour is super unintuitive. Now, some ideas on how it could be improved:

1. Maintain a separate variable with the number of tokens that are available to withdraw. Any time account.unstaked_available_epoch_height is increased, the contract would move the tokens that are already available for withdraw to this new variable;
   • This still has a problem where the tokens would never become available to withdraw if unstake(amount: 1N) was called every 24 hours, for example (at least as long as the staked balance is available).
2. Maintain a log of pending unstakes?
   • Sounds potentially pretty expensive on storage.
3. Maintain a list of tokens pending to release for the upcoming NUM_EPOCHS_TO_UNLOCK epochs of interest.
   • Constant storage per account, that scales with NUM_EPOCHS_TO_UNLOCK rather than the number of operations.
   • Has the "intuitive" behaviour in all cases in that as tokens are unstaked they are always made available to withdraw NUM_EPOCHS_TO_UNLOCK epochs later, no matter what other operations have been executed before withdrawing.

Not sure if any of these changes are feasible or possible though (upgrading contract data sounds like it’d be non-trivial…)