It would be good to move away from piggy-backing onto the release profile. Applications increasingly set compiler options that are incompatible with RPM packaging in the release profile, making it necessary to patch Cargo.toml files.

It looks like cargo supports specifying custom profiles in .cargo/config:
https://doc.rust-lang.org/cargo/reference/config.html#configuration-format

A snippet like this could be written by %cargo_prep:

[profile.rpm]
inherits = "release"
opt-level = %rustflags_opt_level
codegen-units = %rustflags_codegen_units
debug = %rustflags_debuginfo
strip = "none"

The profile used by cargo and rustc could then be specified with --profile rpm instead of --release in the %cargo_build, %cargo_install, and %cargo_test macros:
https://doc.rust-lang.org/cargo/reference/profiles.html#custom-profiles

The values of opt-level, codegen-units, and debug are already set via RUSTFLAGS environment variable / %build_rustflags macro, but setting them in the profile as well would ensure that upstream project settings are overridden in all circumstances.

The most important setting is strip = "none" - without it, upstream projects can specify to strip debuginfo from built binaries, breaking generation of debuginfo subpackages in RPM (because binaries are already stripped).

There are other settings that can be set in a profile, but since most of them affect behaviour of generated code (turning on/off debug assertions, overflow checks, or aborting instead of unwinding in case of panics), I don't think any of them should be set in the profile. If upstream projects explicitly set any of these options, that's likely for a good reason (well, maybe except if they only turn off unwinding because it slightly decreases binary sizes) ...

By inheriting from the release profile, these settings (including whether lto is enabled or not) should be inherited from the upstream project's settings.