Cosmos-sdk: x/stake: Add global redelegation/unbonding index

[ValarDragon]

Currently this function: https://github.com/cosmos/cosmos-sdk/blob/develop/x/stake/keeper/key.go#L158 will have collisions at the same key. e.g.
Delegator has 10 steak bonded to validator A.
Delegator rebonds 3 steak to validator B
Delegator rebonds 5 steak to validator B - Issue here, the key is already in use.

One simple fix is to add an additional component to that key derivation, by appending bytes for a global delegation index, and then incrementing the global delegation index. Anything trying to access that redelegation can iterate over all the different nonces.

From a discussion with @cwgoes

[rigelrozanski]

This also applies to unbonding

Note I don't think that the user should be required to track these nonces, the command should just pick up from the most relevant object (if possible) - going to think about this one a bit more

[rigelrozanski]

I also wanted to note that in adding this we need some slightly more complex backend logic for processing unbonding-delegations or redelegations where there are multiple objects on the same routes. Related: https://github.com/cosmos/cosmos-sdk/issues/1624

[cwgoes]

This is not done, I only implemented a workaround.

[jackzampolin]

So does that mean we can move this out of the game-of-stakes tag? cc @cwgoes

[cwgoes]

So does that mean we can move this out of the game-of-stakes tag? cc @cwgoes

Yup! So moved.

[cwgoes]

@rigelrozanski I think we should do this fairly soon, any additional thoughts or can I start implementing?

[rigelrozanski]

no I think this is a fairly straightforward solution. Just hmu with the R4R PR and I'll review

[cwgoes]

Hmm, how about we just store an array of unbonding delegations or redelegations instead? That seems simpler and requires less keyspace iteration. It doesn't seem too likely that a user would have too many unbonding delegations or redelegations to make the whole array fetch/write inefficient (and we often need to fetch all unbonding delegations / redelegations anyways).

[rigelrozanski]

Seems like a dandy solution

[rigelrozanski]

Upon further investigation, it seems that it may increase complexity to store an array rather than use an index due to how the timestamp indexes are constructed for the auto-unbonding/redelegation maturing. - it's further unfortunate as the looping through the array would separate the queue mature logic from the single timestamp queue logic as is currently, to that _and_ the new array loop at the bond maturing location... will think about this a bit more, but we may end up still wanting to go with an index

---

edit: might still be the best, just going to make the logic a bit weird

---

edit edit: it's not so bad, actually think it's the best solution atm lol