Feat/multiple unstakes

[0xean]

Creating this draft pull request to discuss this option.

If we decide we want to move forward, will continue with additional tests, but a basic POC test exists.

Some notes:

• indexes are sequential and shift. We can easily manage this off chain. The biggest downside to this is if a user calls withdraw(0) and withdraw(1) without waiting for transactions to be processed, the later will certainly revert. Its an edge case, but a possibility.
• There is no clean solidity based way to iterate this array and modify its length at the same time without some pretty heavy gas hits with re-allocating the entire array to shift elements in place.
• due to the ability for the cooldown period to change, we could never guarantee that indexing was chronological in the array anyways.

TLDR: we can do it, but there are just tradeoffs here. Is it better to allow it or not?

[0xean]

adding much more testing and a better algorithm for calling withdraw()

please take another pass, marking as "ready for review"

[kaladinlight]

One more thought regarding user interaction optimization: withdraw() could instead withdraw all cooled down unstaking requests instead of the most recent one each call.

[0xean]

One more thought regarding user interaction optimization: withdraw() could instead withdraw all cooled down unstaking requests instead of the most recent one each call.

Yes, I thought about this also.

The complexity here is not trivial because we need to modify the array index while iterating the same array. I don't know a graceful way to handle this in solidity without introducing a significant amount of code that I don't think is really warranted. If you have an easy way to do it, I think its worth discussing.

[0xean]

@gomesalexandre - ready for another pass. Good to treat as high risk, so would prefer 2 stampers.