Allow registries to patch crates

[epage]

Cargo has a patch feature today to address bugs and other issues in packages. When people are blocked, there are security issues, or legal issues, an organization managing may want to quickly deploy these patches.

One venue for doing this is through the registry itself, especially when the registry is managed by a company where software policy is top-down. This would need

• A simply way of distributing patches, e.g. Remove ExecEngine abstraction #3177.
• A way for cargo to get these patches from the registry, e.g. reading from a mutable metadata database (see https://blog.rust-lang.org/inside-rust/2024/03/26/this-development-cycle-in-cargo-1.78.html#why-is-this-yanked)

In rare circumstances, a community registry like crates.io may want to do this as well, e.g. to do something like #14452.

• Users would need a way to opt-out
  • this could also be important for testing within an organization

Policy for crates.io is being left to a future RFC by that team. It should likely consider audit tools and rules including

• Who all signs off on patches? Suggestion: at least someone with publish permissions along with someone from the Project
• How do we verify patches? Suggestion: a crater run
• What rules apply to patches? Suggestion: must match behavior in a newer published version (requires audit)

[epage]

First steps

• Yanked messages as its the first place for us to explore mutable metadata for registries
• Starting back up on [experiment] patch with patch files #13779
  • unidiff format would need to be worked out (delegating to a tool is not ideal)
  • Resolving with patched Cargo.toml was a problem, maybe we can punt on that