Select distribution strategy for rustfix/cargo-fix

[alexcrichton]

Currently we distribute cargo fix subcommand through cargo install cargo-fix. I discussed locally on discord though with @aturon and @Mark-Simulacrum that I'd personally prefer to distribute cargo fix by default to users. In any case, a decision should be made!

I believe we have one of three options here to us:

• Do nothing - continue to ship cargo fix through cargo install. This has the benefit of not needing any work to get it done. It has a downside, however, of requiring users to opt-in to acquiring cargo fix. Additionally it introduces the possibility for version skew where cargo fix is either too old or too new by accident.
• Ship a rustup component - here we'd enable something like rustup component add cargo-fix or automatically enable it by default for new installations. This allows us to control versioning and provide it by default, but it requires a relatively large amount of rustbuild/dist work.
• Merge cargo-fix into Cargo - here we'd merge the cargo fix subcommand inside the rustfix repository to Cargo itself upstream, depending on the rustfix crate from crates.io. This has the benefits of shipping a rustup component but it's a little easier to do in terms of distribution. The downside of this approach is that, like a component, it ties rustfix to the trains so getting out a hotfix is more fuss (needs a full Rust release)

I'm personally inclined to go the route of "merge cargo-fix into Cargo". I don't believe rustfix has had many major changes and/or big bugs reported, so merging it into Cargo should require little-to-no fuss and the need for a hotfix should be pretty low. I'm curious to hear what others think though!

cc @killercup

[killercup]

Merging cargo-fix into cargo sounds good to me. The code base is still quite small -- especially if we were to only move the cargo specific parts into cargo and keep the rustfix (library) crate separate (it's also not that big, though). One reason to keep the rustfix lib separate is that it is also used in compile test.

We might want to refactor some of the CLI code to re-use the existing cargo infrastructure but this is neither that big of an effort nor necessary for the first integration PR.

[joshtriplett]

We should consider doing the same for cargo fmt.

[alexcrichton]

I've created a PR for moving this into Cargo at rust-lang/cargo#5723

[Mark-Simulacrum]

Closing as this seems done.