feat: add CI action to check for toolchain updates

[lima-limon-inc]

Closes #140
Depends on #155

(Sidenote: in order to ease a PR review, I split this PR into two. #155 which only comprises the splitting of midenup into a bin and lib component and this PR which adds the update-manifest package).

This PR includes a new workflow for midenup's CI .github/workflows/new-release.yml, which is scheduled to run every hour.

The update-manifest script, iterates over all the components in the various channels in the manifest and checks whether a newer patch release was made (this is checked in cargo's crate index). If so, it updates the manifest and performs a PR with the newly made changes.

[lima-limon-inc]

Sidenote: This PR is pointing to the fabrizioorsi/i147-workspace branch. If the workspace approach is not desired, this can be easily rebased to the main branch.

[bitwalker]

This will allow anyone with a token that can trigger a workflow dispatch, the ability to inject malicious shell script which will execute with write access to the contents of the repo and all pull requests.

IMO, the better way to approach this sort of thing is to use GHA's cron feature to run a workflow once an hour that checks all of the existing repos for new releases, and if found, updates the manifest accordingly (or if we want to be even stricter about it, submits a PR to do so).

While that approach is more fragile (or at least, requires repos to use a convention for releases, which we should be doing anyway), it doesn't require adding anything to the GHA workflows of other repos, and has the advantage of not leaving a potential exploitable hole in the workflow of this repo (not saying it is possible to do real damage at the moment, just that the potential would exist, and specifically for a tool like midenup, supply-chain security is crucial).

Anyway, I know this PR is still in draft status, but figured I'd leave my notes while you're still working through it.

[lima-limon-inc]

This will allow anyone with a token that can trigger a workflow dispatch, the ability to inject malicious shell script which will execute with write access to the contents of the repo and all pull requests.

Great point, thanks!

IMO, the better way to approach this sort of thing is to use GHA's cron feature to run a workflow once an hour that checks all of the existing repos for new releases, and if found, updates the manifest accordingly (or if we want to be even stricter about it, submits a PR to do so).

Noted, I've reworked the PR using cron. Like I mentioned in the description, the large diff comes from the fact that I had to add a library component to midenup in order for the update-manifest to import its structure.

[lima-limon-inc]

I'll update this PR to include the missing Makefile directives and also update the Manifest's timestamp

Edit: Done! Like I mentioned in the description, I went with splitting this PR into two in order to ease reviewing.

[lima-limon-inc]

While I believe it's useful to have mechanisms in place that automatically check for updates, I believe the assumption under which this PR is based upon might be technically wrong.

This PR presupposed that when a component had a new release with increase in its patch number, its required miden-vm version stayed the same.
However, this is not the case in miden-debug:

• Version 0.4.6 uses vm version 0.20. See Cargo.toml
• Whilst, version 0.4.5 uses 0.19. See Cargo.toml.

So the mechanism to determine what requires an update probably requires a rework.

[bitwalker]

This PR presupposed that when a component had a new release with increase in its patch number, its required miden-vm version stayed the same. However, this is not the case in miden-debug:

• Version 0.4.6 uses vm version 0.20. See Cargo.toml
• Whilst, version 0.4.5 uses 0.19. See Cargo.toml.

So the mechanism to determine what requires an update probably requires a rework.

In the case of miden-debug, this appears to be due to the fact that the automatic version bumping behavior of cargo-semver-checks did not identify any technically breaking changes with the change to v0.20 that would break downstream consumers of the miden-debug API (which is surprising, but might be technically true). Had we done the release manually, we would have done so as 0.5.0 though for sure. The recent migration to v0.21 did trigger a version bump to 0.5.0, but that may have been due to other changes, it is unclear.

In any case, I agree that we can't rely on the version number here to communicate a specific dependency on any given miden-vm (or other component) release. We could do something heuristically though, such as looking at the contents of Cargo.toml to determine what version of miden-vm is being depended upon.

I'm also entirely OK with requiring that we adhere to some standardized metadata format in GitHub release notes for this, so long as we get buy-in from all the teams on what that looks like, and the process for it, e.g. something like one or more declarations like Requires: miden-vm=^0.22 somewhere in the release notes, so long as the declaration is at the start of a new line. Anyway, this is something we can continue discussing for a bit yet, since our release process isn't structured enough to even try automating it with any confidence yet IMO.

[lima-limon-inc]

In any case, I agree that we can't rely on the version number here to communicate a specific dependency on any given miden-vm (or other component) release. We could do something heuristically though, such as looking at the contents of Cargo.toml to determine what version of miden-vm is being depended upon.

Completely agree, I believe the Cargo.toml file is the only real "source of truth" when it comes to compatibility resolution.

A while ago I began writing a crate for a proof of concept trying to tackle this very problem. I had used https://crates.io/crates/cargo_toml which seemed to be a nicer approach than greping the Cargo.toml. Maybe it'd be worth trying again.