Moving away from upgradeName-based control flows

[mujahidkay]

What is the Problem Being Solved?

Currently, for cases where we require different configurations based on different networks (devnet, emerynet, mainnet), we make use of specific upgrade names to trigger a specific control flow which maps to a specific configuration. This is the most recent example from upgrade 18. Ideally, in the best case scenario, we should only have one upgrade name and our core logic should determine which control flow to execute.

Description of the Design

The design of the problem is pretty simple. Instead of having network specific upgrade names, we should standardize it to a singular name. In case of multiple RCs during release, we would need new upgrade names for re applying the upgrades but that is mostly for internal testing and use. And even then, the control flow is not dependent on those upgrade names. The goal behind this is to minimize the confusion regarding upgrade names w.r.t external validators - as was observed multiple times during upgrade 18. Having a standardized agoric-upgrade-X each time moving forward will help in minimizing that confusion.

Security Considerations

None that I can think of.

Scaling Considerations

None

Test Plan

Kept as is. The only thing that will be different is how the specific flow is being triggered.

Upgrade Considerations

This is primarily for upgrades so this is all upgrade.