Update workspace to Rust edition 2024

[Guara92]

Summary

This PR updates the entire workspace to Rust edition 2024, resolving #1414.

Changes

• Updated edition = "2024" in all crate Cargo.toml files
• Fixed code compatibility issues for Rust 2024:
  • Added #[allow(unsafe_code)] to global_init() function of crates/lib/src/cli.rs for std::env::set_var
• Bumped MSRV to 1.85.0 in bootc-lib and system-reinstall-bootc
• cargo fmt --all
• many variables has been renamed from gen to generator because gen is now a reserved keyword

MSRV Considerations

The MSRV is set to 1.85.0 (minimum for edition 2024), but some dependencies
require higher versions:

• composefs (git dependency) requires 1.88.0
• openssh-keys@0.6.5 requires 1.90.0

RHEL 9 Availability: According to the public UBI9 repository, RHEL 9
currently ships rust-toolset-1.88.0-1.el9

This means:

• bootc-lib cannot build with Rust < 1.88.0
• system-reinstall-bootc cannot build with Rust < 1.90.0

Question for maintainers: Should the rust-version fields be updated to
reflect actual dependency requirements (1.88.0 and 1.90.0 respectively)?

Notes on unsafe usage

The global_init() function now uses #[allow(unsafe_code)] because
std::env::set_var is marked unsafe in Rust 2024 edition. This is safe
because:

1. The function is explicitly documented to be called early in main()
2. It's called before any threads are spawned (see crates/cli/src/main.rs)
3. This workaround is needed for bootc-image-builder compatibility

I'm seeking maintainer approval for this localized unsafe exception, as the
project policy is -D unsafe-code workspace-wide.

Closes #1414

[gemini-code-assist]

Code Review

This pull request effectively updates the entire workspace to the Rust 2024 edition. The changes, including updating Cargo.toml files, running cargo fmt, and handling the new unsafe requirement for std::env::set_var, are well-executed and necessary for the edition upgrade. The justification for the unsafe block is clear and sound. I also appreciate the readability improvements from renaming variables in a few places.

I've added two comments supporting your suggestion to update the rust-version in bootc-lib and system-reinstall-bootc to reflect the actual MSRV required by their dependencies. This will ensure the crate metadata is accurate and helps prevent build issues for contributors.

Overall, this is a great contribution that keeps the project up-to-date with the latest Rust standards.

[gemini-code-assist]

As you correctly pointed out in the pull request description, while 1.85.0 is the minimum for the Rust 2024 edition, this crate has dependencies (like composefs) that require a newer Rust version (1.88.0). To ensure the MSRV is accurate and prevent build failures for users with older toolchains, it's best to update this field to reflect the actual minimum required version.

Suggested change

	rust-version = "1.85.0"
	rust-version = "1.88.0"

[gemini-code-assist]

Similar to bootc-lib, the rust-version here is set to 1.85.0. As you've noted, a dependency (openssh-keys@0.6.5) requires Rust 1.90.0. To provide an accurate MSRV for this crate, it would be best to update this to 1.90.0.

Suggested change

	rust-version = "1.85.0"
	rust-version = "1.90.0"

[cgwalters]

Yeah, can be a followup

[cgwalters]

We don't have CI gating on actually testing our MSRV right now, I'm not opposed to it but we don't have anyone asking for it either.

It looks like the openssh-keys bump came in coreos/openssh-keys#115 (comment)

[cgwalters]

Thanks so much for doing this! Due to all the import and rustfmt changes this will be a conflict fest until merging, and I don't see a reason not to merge now, so let's do it!

[cgwalters]

That said, this was my bad in not submitting a patch for this at the time, would still make sense to do. Then at least we could in theory eventually remove this code.