[Defect] Be able to re-propose Upgrade with the same name if we don't get a quorum of Trustee approvals by the specified block height (time)

[ashcherbakov]

How to reproduce:

• Propose an upgrade at height X
• Don't have a quorum of approvals by the height X
• Got the quorum after the X hight is reached

Actual Behaviour:

• An error is returned on the last approvals: "upgrade cannot be scheduled in the past"
• The Upgrade Proposal is not removed (will be there forever)
• It will be not possible to re-propose upgrade with the same name. As the upgrade name is bound to the release, a new release with a new upgrade name will have to be issued.

Expected Behaviour:

• An error is returned on the last approvals: "upgrade cannot be scheduled in the past"
• Upgrade Proposal is removed
• It's possible to re-propose upgrade with the same name, so that upgrade can be happen without a need to re-issue a release.

Reason:

• ScheduleUpgrade is called before RemoveProposedUpgrade in https://github.com/zigbee-alliance/distributed-compliance-ledger/blob/master/x/dclupgrade/keeper/msg_server_approve_upgrade.go#L53.
• ScheduleUpgrade will fail if the upgrade height is less than the current height, see https://github.com/cosmos/cosmos-sdk/blob/main/x/upgrade/keeper/keeper.go#L172

Proposed Fix:

• Call RemoveProposedUpgrade before ScheduleUpgrade in https://github.com/zigbee-alliance/distributed-compliance-ledger/blob/master/x/dclupgrade/keeper/msg_server_approve_upgrade.go#L53

[abdulla-ashurov]

@ashcherbakov, @uabjabborov
Wrote the implementation for this ticket #344, but we have another problem:

• We proposed an upgrade and then we try to approve the upgrade (when current block height > plan update height).
  The problem is that after that we return an error and the library ignores all changes that have occurred in this iteration That is we don't remove Proposed upgrade.

We can offer two solutions to this problem:

1. We can add a new command reject-proposed-upgrade, which helps us remove updates from the entity Proposed upgrade. This command will work through voting and like other commands.
2. We can add a new command revoke-own-proposed-upgrade for Trustee, which proposed upgrade. This command helps us remove updates from a Trustee, which proposed the upgrade.

[ashcherbakov]

Both options make sense.
We can also consider a 3d option:
When proposing a new upgrade, if there is an expired upgrade proposal with the same name, we remove the proposal and add a new one (with the same name and all votes cleared) instead of failing with "Proposed upgrade with name=%v already exists on the ledger".