ci: adds release workflow for automated draft releases

[dutterbutter]

What 💻

• Adds release.yaml to the CI
• Adds push tag workflow trigger for check and test workflows
• Updates ci deps for rust cache
• Adds make command
• Adds a Cross.toml file for release.yaml workflow

Why ✋

• Automates the preparation of binaries for multiple targets and drafts a release.
• When we push a tag (e.g. v0.0.1-alpha) it will trigger the test, checks, and release workflows
• Outdated CI dep
• make rust-<target> command added to makefile for ci convenience and readability
• Toml file is used for cross configuration in the ci. See docs here: cross

Evidence 📷

The release will be presented as such 👇 :

Notes 📝

Specifics on the release workflow 👇

Overview: release.yaml

This PR introduces a new release pipeline aimed at automating the creation of GitHub releases, ensuring consistency and efficiency in our delivery process. The workflow is inspired by practices from reth and Lighthouse.

Release Workflow

1. Extract version: The workflow extracts the version from the Git tag. The Git tag is being used to trigger the workflow.
2. Build: A matrix build is executed to generate binaries for multiple architectures.
3. Draft Release: A release draft is prepared with an automatically generated changelog and attached binaries.

First Run

On the first execution of this workflow, the "All Changes" section of the release draft will be empty. This behaviour occurs because the action fetches commits between tags. Since there will be no prior tag for the first run, it does not populate this section. However, for subsequent runs, this section will feature all commits up to the given tag. The first run we will have to do so manually by running git log main --oneline and adding the commits.

Draft Release

The workflow creates a draft release instead of a public one. This approach is intentional. It allows us to:

• Add any additional commentary.
• Ensure checks and test CI jobs pass successfully.
• Prepare announcements or tweets related to the release prior to the release.
• Ensure it works as intended, and all the changes intended are present.

Once the draft is reviewed and any required changes are made, we can finalize and create the release accordingly.

Note: The binaries links in the table will not resolve until the release is made. That is, when a release is in "draft" form on GitHub, it is given an untagged-... URL. So when the release is made it will be tagged with the corresponding tag.

Triggering the Release Pipeline

To trigger the release pipeline, you'll need to create and push a Git tag. Here are the commands:

# Create a tag
git tag -a v[VERSION_NUMBER] -m "Release v[VERSION_NUMBER]"

# Push the tag to the repository
git push origin v[VERSION_NUMBER]

Replace [VERSION_NUMBER] with the desired version number. This will trigger the check.yaml and test.yaml workflows, and release.yaml.

[MexicanAce]

LGTM