update the Order check ValidateUpgradeFields util method to allow for all supported Order types

[charleenfei]

Summary

In a previous version of the upgradability spec, a channel upgrade could only update the Ordering of the channel within a subset of the existing ordering (ie: Unordered channels could not be upgraded to Ordered, whereas Ordered could be updated to both Unordered and Ordered.) However, because the latest iteration of the spec allows for packets to finish their lifecycles, we can now upgrade channel ordering to any type of ordering, provided it is supported by the connection.

The util method for validating upgrade fields should reflect this.

---

For Admin Use

• Not duplicate issue
• Appropriate labels applied
• Appropriate contributors tagged/assigned

[damiannolan]

Partially addressed by removing dead code in #3634.

We should add the following in a follow up PR to ensure the order is supported by the underlying connection. ref

getVersions := connectionEnd.GetVersions()
if len(getVersions) != 1 {
    return "", nil, errorsmod.Wrapf(
	connectiontypes.ErrInvalidVersion,
	"single version must be negotiated on connection before opening channel, got: %v",
	getVersions,
    )
}

if !connectiontypes.VerifySupportedFeature(getVersions[0], order.String()) {
    return "", nil, errorsmod.Wrapf(
	connectiontypes.ErrInvalidVersion,
	"connection version %s does not support channel ordering: %s",
	getVersions[0], order.String(),
    )
}

This should probably be reflected in the spec also if not already. cc @AdityaSripal

[crodriguezvega]

Closed by #3774.