refactor PutUnbondingOnHold handling

[MSalopek]

Problem

cosmos-sdk v0.47 introduced a feature called CancelUnbonding which enables users to cancel unbonding operations.

To make this operation feasible, UnbondingDelegationEntries that were created on the same height are now merged into a single entry (previously there would be multiple entries).

This created a problem for AfterUnbondingInitiated hook users where the hook could be called with an UnbondingId that does not exist (because it was merged into another unbonding entry).

Since the changes are state-machine breaking, the feature will be available in cosmos-sdk > 0.47. To accomodate for the change in behaviour provider code had to be modified to handle cases where PutUnbondingOnHold operation could fail because the unbonding ID does not actually exist in state.

This change should be reverted when ICS migrates to cosmos-sdk v0.47.

Context:
Previous handling of PutUnbondingOnHold would treat missing unbondingId as corrupted state. Since missing unbondingIds are to be expected, we cannot panic the chain any more since that is a valid case and not a state corruption.

Closing criteria

Refactor PutUnbondingOnHold calls to reflect changes in cosmos-sdk >0.47.

The behavior must match the one in ICS@v1.2.0-multiden.

Problem details

Additional problem context:

• https://github.com/cosmos/cosmos-sdk/pull/16043/files
• [Bug]: AfterUnbondingInitiated can be called with invalid unbondingID cosmos-sdk#16042

Original PR & Issue introducing the change in cosmos-sdk:

• fix: fix the cancel unbond  cosmos-sdk#12967
• staking msgServer.CancelUnbondingDelegation could possibly choose mismatching UnbondingDelegationEntry to cancel cosmos-sdk#12931

This is the PR that made the change that needs to be reverted:

• deps!: support cosmos-sdk-v45-ics-lsm integration #1120