snap: install compatible prebuilt cargo-c

[adombeck]

Fresh broker Snap builds fail when cargo-c is compiled with Rust 1.94: new cargo-c releases require a newer compiler before libhimmelblau can build.

Install cargo-c's verified prebuilt release binary instead, decoupling its own build-time MSRV from the broker toolchain. The shared installer is used by both the Snap build and Himmelblau generator, and validates architecture- specific SHA-256 checksums.

Add a weekly workflow that opens a PR only for new stable cargo-c GitHub releases. It updates the pinned version and release-asset checksums so each upgrade is reviewed and validated by the normal PR checks.

Closes #1748
UDENG-11052

[adombeck]

The snap build has been failing for me locally and this fixes it. I'm not happy with the fix though, because dependabot won't update this pinning of the cargo-c version.

[nooreldeenmansour]

I cherry-picked your commit, along with a8d9794 in #1723 to fix the failing CI builds..

We need to ensure this doesn't occur again, Copilot suggests the following solutions:

1. Install cargo-c as a prebuilt binary (recommended)
   Skip compiling cargo-c from source entirely — e.g.  cargo binstall cargo-c  or download the GitHub release tarball for the host triple. Since it's not built with the project's pinned rustc, cargo-c's own MSRV becomes irrelevant. Fully decouples the two concerns; survives future cargo-c releases with no maintenance.

2. Build cargo-c with an unpinned/default toolchain
   Explicitly invoke  cargo +stable install --locked cargo-c  (or a temporary  rustup run stable ... ) instead of letting the ambient  rust-toolchain.toml  govern the install. cargo-c is a dev tool, not project source — it doesn't need to match the pinned MSRV. Simple one-line change in both scripts.

3. Centralize the version pin (if keeping  cargo install cargo-c@ )
   At minimum, stop hardcoding the version string independently in  generate.sh  and  snapcraft.yaml . Put it in one place (e.g. an env var/file sourced by both) so a future bump/pin only needs one commit instead of two. Doesn't fix the coupling, just the duplication.

4. Bump  rust-toolchain.toml  forward (e.g. 1.95+)
   Works, and is precedented (same fix used 4 months ago for the same symptom). But it's reactive — resets the clock until cargo-c's next MSRV bump — and has wider blast radius (affects clippy/lints for the whole crate, not just tool install).

Suggested order: try #1 first; fall back to #2 if binaries aren't available for the target platform; avoid #4 as the primary fix since it's already proven to recur.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 84.97%. Comparing base (b7bc012) to head (c3dacc2).
⚠️ Report is 30 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #1747   +/-   ##
=======================================
  Coverage   84.97%   84.97%           
=======================================
  Files          25       25           
  Lines        1943     1943           
=======================================
  Hits         1651     1651           
  Misses        292      292           

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[adombeck]

Install cargo-c as a prebuilt binary (recommended)

I did that now. I'll wait for CI results of the "Build broker snap" step before marking as ready for review

[Copilot]

Pull request overview

This PR fixes Snap build breakages caused by cargo-c’s increasing Rust MSRV by switching to a pinned, checksum-verified prebuilt cargo-cbuild binary, decoupling broker builds from cargo-c’s compile-time requirements. It also adds automation to keep the pinned cargo-c version and checksums up to date via a scheduled workflow PR.

Changes:

• Update the msentraid Snap build to install a prebuilt cargo-cbuild instead of compiling cargo-c from crates.io.
• Add a shared install-cargo-c script that downloads the correct release asset per-architecture and validates SHA-256.
• Add a scheduled GitHub workflow to open automated PRs when a new stable cargo-c release is available (updating version + checksums).

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 1 comment.

File	Description
snap/variants/msentraid/snapcraft.yaml	Switches Snap build step to use the shared prebuilt cargo-cbuild installer (and adds curl).
authd-oidc-brokers/tools/install-cargo-c	New installer script to fetch and checksum-verify cargo-cbuild release assets for x86_64/aarch64.
authd-oidc-brokers/internal/providers/msentraid/himmelblau/generate.sh	Uses the shared installer so generator builds don’t depend on compiling cargo-c.
.github/workflows/update-cargo-c.yaml	New scheduled workflow to bump pinned cargo-c version/checksums via automated PR.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[adombeck]

I'll wait for CI results of the "Build broker snap" step before marking as ready for review

seems to work fine

[nooreldeenmansour]

LGTM, few small suggestions