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: #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