Improve CI and PR process

[Mirko-von-Leipzig]

Some ideas, not all are good :)

---

Restrict workflows to only run the latest commit in a PR. Code example here. Essentially this cancels any in-progress workflows for the PR whenever it is updated. This prevents notifications for failed workflows from old commits for example. In addition to saving CI time as workflows are queued.

---

Switch the default branch to next. This will become the branch PRs are opened against by default. Downside is that cloning also defaults to this branch, meaning users will clone the wrong branch.

---

Cache the CI runs, this will drastically speed up CI times. Tests currently compile in ~2 minutes or roughly half the CI total time. Caching even just the latest next branch would improve every PR and commit. This also applies to lint and doc workflows and is probably more impactful there.

---

Consider a codeowners file.

[bobbinth]

Restrict workflows to only run the latest commit in a PR. Code example here. Essentially this cancels any in-progress workflows for the PR whenever it is updated. This prevents notifications for failed workflows from old commits for example. In addition to saving CI time as workflows are queued.

This would be great! I don't see any downsides to doing this.

Switch the default branch to next. This will become the branch PRs are opened against by default. Downside is that cloning also defaults to this branch, meaning users will clone the wrong branch.

We considered this a couple of times in the past and the main reason we kept it the way it is now is that we want the default branch be consistent with what is on crates.io (i.e., a kind of "latest stable").

Cache the CI runs, this will drastically speed up CI times. Tests currently compile in ~2 minutes or roughly half the CI total time. Caching even just the latest next branch would improve every PR and commit. This also applies to lint and doc workflows and is probably more impactful there.

This would be awesome and we actually have an issue for something similar in miden-base.

Consider a codeowners file.

I haven't used this in the past - but it seems like a good idea.