[Feature] Support program upgrades.

[d0cd]

This PR supports program upgradability in Leo. To that end we:

• introduce a new command leo upgrade which is used to deploy the upgrade to the network.
• supports upgrade configurations in the manifest.
• adds support for constructors in the compiler. The compiler also checks that certain default constructors are well formed.
• refactors the Network trait from the compiler. and also closes:
• #28678
• #28673

See this issue to track snarkVM support.

To Reviewers. This PR has ballooned since it's inception. Let me know if you'd like me to break it up into pieces.

[d0cd]

Are we sure we like the design with the upgrade mode config in program.json ?

This is a fair question. Ultimately, it comes down to what we're trying to optimize for. If it's ease of use, I think the above suggestions are a good way to go.

However, with constructors I've been thinking more about preventing mistakes. When a developer chooses a new constructor, we want to make the switch deliberate and hard to modify. Once the program is deployed, the decision is locked in. I'm seeing the program.json as a second point of confirmation. Especially with AI coding, it's very easy for users to mistakenly modify their constructors (not saying that program.json prevents that, but it does make it a bit harder.)

Perhaps there's a better approach to guarantee safety here.

[d0cd]

Here's a few random comments. I want to be able to exercise this code before I approve though.

@mikebenfield I've updated the snarkOS PR. You should now be able to run a working devnet.

[d0cd]

One thing that's not clear to me is how we expect this to roll out. Are we going to allow programs with no constructors or not? Are we going to merge this, and just have the mainnet branch of Leo depend on an unreleased Snarkvm commit for now?

The implementation supports programs without constructors. leo deploy checks for the consensus version and tells users whether the network expects constructors or not.

You bring up a good question on merging into mainnet. I think this PR is a strong motivation for bringing back a staging branch into our merge process. So the flow would look like mainnet <-- staging <-- PRs. We will still only cut releases for mainnet, but the staging branch well let us merge PRs without blocking development.