upgrade client bypasses the user-defined upgrade path

[Farhad-Shabani]

Problem Statement

In regards to the client upgradability feature, @yito88's issue in #1297 raised a question:
Why that's allowed to pass an upgraded client state with just single element in the upgrade_path specifying only the commitment prefix, regardless of whether users entered an upgrade path.

Typically, chains need to work with an upgrade_path of size two, where the first element is the module prefix and the second is the upgrade path. In SDK-based chains, this is represented as ["upgrade", "upgradedIBCState"].

I realized that in our implementation, we bypass the second element, assuming all chains store upgrade states under the "upgradedIBCState" node. This is incorrect, as the upgrade path should be constructed based on the user's choice of upgrade path (second element of the upgrade_path). Cosmos SDK chains use upgradedIBCState, but non-Cosmos chains may not necessarily. Therefore:

Solution

1. We should see what's the size of an upgrade_path. If two: the first as the prefix and the second as the path.
   If one, means that prefix is not passed (As in some projects, that's not the case, and we allow empty commitment prefixes), then the upgrade path only contains the path.
2. The last element should be used to construct the upgrade path.
3. Allow UpgradeClientPath to take an arbitrary prefix instead of the UPGRADED_IBC_STATE constant. Thought still the UPGRADED_IBC_STATE can be the default one.

Version

<= 0.53.0