refactor(x/staking): Migrate UnbondingID to collections

[likhita-809]

Description

Closes: #16386

---

Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

• included the correct type prefix in the PR title
• added ! to the type prefix if API or client breaking change
• targeted the correct branch (see PR Targeting)
• provided a link to the relevant issue or specification
• followed the guidelines for building modules
• included the necessary unit and integration tests
• added a changelog entry to CHANGELOG.md
• included comments for documenting Go code
• updated the relevant documentation or specification
• reviewed "Files changed" and left comments if necessary
• run make lint and make test
• confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

• confirmed the correct type prefix in the PR title
• confirmed ! in the type prefix if API or client breaking change
• confirmed all author checklist items have been addressed
• reviewed state machine logic
• reviewed API design and naming
• reviewed documentation is accurate
• reviewed tests and test coverage
• manually tested (if applicable)

[julienrbrt]

I think there is a wrong usage of .Next()

[julienrbrt]

I see that TestIncrementUnbondingID expect it to start at 1 🤔.
Do you know why is that?

[likhita-809]

I see that TestIncrementUnbondingID expect it to start at 1 thinking. Do you know why is that?

IDK, but in the previous behaviour it seems like only positive integers starting from 1 are returned here.
I'm assuming that since this func increments and returns unique id, naturally it all starts with 1 rather than 0. I don't really know if there's any underlying meaning here.

[julienrbrt]

I see that TestIncrementUnbondingID expect it to start at 1 thinking. Do you know why is that?

IDK, but in the previous behaviour it seems like only positive integers starting from 1 are returned here. I'm assuming that since this func increments and returns unique id, naturally it all starts with 1 rather than 0. I don't really know if there's any underlying meaning here.

There must be a nicer way to set it start at one. Right now at each call of IncrementUnbondingID we basically do two sets.
If we need a default value that starts at one, we possibly should simply call that in InitGenesis.
In an existing chain, I believe the current behavior in this PR (the two sets) would be off by one then, given that we start from an existing number (and not 0 like in the unit test).

[likhita-809]

In an existing chain, I believe the current behavior in this PR (the two sets) would be off by one then, given that we start from an existing number (and not 0 like in the unit test).

I didn't get this, can you elaborate what needs to be done please?

[julienrbrt]

In an existing chain, I believe the current behavior in this PR (the two sets) would be off by one then, given that we start from an existing number (and not 0 like in the unit test).

I didn't get this, can you elaborate what needs to be done please?

Nvm this, I was confused.
Given the current logic only the k.UnbondingID.Set isn't necessary in IncrementUnbondingID (As .Next() calls .Set already).

[julienrbrt]

lgtm!

[atheeshp]

Lgtm