Refine suggestions about missing components

[rami3l]

Closes #3418. I also cleaned up the current code a bit along the way.

cc #2355

[rami3l]

@rbtcollins Looking at the blackbox test suite, it seems to me that this fix is more than what it seems to be.

In toolchain updates, component_unavailable_msg

rustup/src/errors.rs

Line 173 in a4dd7d0

fn component_unavailable_msg(cs: &[Component], manifest: &Manifest, toolchain: &str) -> String {

does get called, but the generated error then gets caught and re-thrown

rustup/src/dist/dist.rs

Lines 938 to 946 in a4dd7d0

	Some(RustupError::RequestedComponentsUnavailable {
	components,
	manifest,
	toolchain,
	}) => Err(anyhow!(DistError::ToolchainComponentsMissing(
	components.to_owned(),
	Box::new(manifest.to_owned()),
	toolchain.to_owned(),
	))),

to components_missing_msg

rustup/src/dist/dist.rs

Line 45 in a4dd7d0

fn components_missing_msg(cs: &[Component], manifest: &ManifestV2, toolchain: &str) -> String {

, which instead suggests using a minimal profile, so the original suggestion in the former (uninstall the component in question) might not be applicable at all anymore, as the error message from the former can only be seen in some edge cases (like adding miri to stable, but not upgrading to a new nightly which lacks rls).

To move this fix forward, I could simply remove the suggestion in component_unavailable_msg, however, I want to know more about the semantic differences between these two functions in order to make the final decision.

For example, since this help message is very well-written, I wish to be able to see it in toolchain updates as well:

rustup/src/errors.rs

Lines 22 to 28 in a4dd7d0

	const TOOLSTATE_MSG: &str =
	"If you require these components, please install and use the latest successful build version,\n\
	which you can find at <https://rust-lang.github.io/rustup-components-history>.\n\nAfter determining \
	the correct date, install it with a command such as:\n\n \
	rustup toolchain install nightly-2018-12-27\n\n\
	Then you can use the toolchain with commands such as:\n\n \
	cargo +nightly-2018-12-27 build";

[rami3l]

Note: dist::manifestation::tests::unavailable_component and friends test rustup::dist::manifestation::Manifestation::update directly (by checking the very rustup component remove suggestion), which happens before the catch-rethrow dance in rustup::dist::dist::try_update_from_dist_, so these tests are expected to fail at the moment.

... and they are not accurate anyway since the string form of those errors (before the catch-rethrow dance) is NOT ALWAYS visible to end users, which might cause further confusions for maintainers later on.

[rami3l]

I've yet to see any use case or test case that disobeys the observation stated in 6b5cb9f 's commit message.

Therefore, I think by now it is reasonable to do the following:

• Add a new blackbox test case to ensure that Confusing component add error message #3418 does get fixed.
• Move TOOLSTATE_MSG to dist to serve toolchain-wide operations (since it also talks about toolchain changes) by appending it to the end of component_missing_msg's output.

[rbtcollins]

I've yet to see any use case or test case that disobeys the observation stated in 6b5cb9f 's commit message.

Therefore, I think by now it is reasonable to do the following:

* [x]  Add a new blackbox test case to ensure that [Confusing `component add` error message #3418](https://github.com/rust-lang/rustup/issues/3418) does get fixed.

* [x]  Move `TOOLSTATE_MSG` to `dist` to serve toolchain-wide operations (since it also talks about toolchain changes) by appending it to the end of `component_missing_msg`'s output.

seems reasonable to me

[rami3l]

I've yet to see any use case or test case that disobeys the observation stated in 6b5cb9f 's commit message.
Therefore, I think by now it is reasonable to do the following:

* [x]  Add a new blackbox test case to ensure that [Confusing `component add` error message #3418](https://github.com/rust-lang/rustup/issues/3418) does get fixed.

* [x]  Move `TOOLSTATE_MSG` to `dist` to serve toolchain-wide operations (since it also talks about toolchain changes) by appending it to the end of `component_missing_msg`'s output.

seems reasonable to me

@rbtcollins ... and those two tasks have been done, together with a new black box test case for the latter.
Would you mind reviewing my changes?

[djc]

Please keep unrelated changes in separate commits, makes it much easier to review.