rustup_mode: add toolchain install --allow-downgrade option

[payload]

In case you have an already installed nightly toolchain
and you want to install a nightly toolchain with a component
which is not available in the installed toolchain,
rustup is searching for the most recent nightly supporting
all requested components and which is not older than the currently
installed nightly.

With this option set it will also search for toolchains older
than the currently installed one.

• add a test for downgrading

Should fix #2067

[kinnison]

Some initial feedback.

[payload]

The failed CI run ended with the message:

Copying from /checkout/target/x86_64-unknown-linux-gnu/release/rustup-init to /checkout/target/x86_64-unknown-linux-gnu/tests/running-test-ryUcXF/rustup-exeTGkmi4/rustup

running "/checkout/target/x86_64-unknown-linux-gnu/tests/running-test-ryUcXF/rustup-exeTGkmi4/rustup" "set" "default-host" "x86_64-unknown-linux-gnu"

thread 'env_override_beats_file_override' panicked at 'failed to run test command: Os { code: 26, kind: Other, message: "Text file busy" }', src/libcore/result.rs:1165:5

I consider this flakyness of the underlying system, probably some filesystem hickup. I don't know if it is probably related to code in rustup set default-host which could be more robust against yet uncertain filesystem races.

@kinnison what do you think of it?

[kinnison]

@payload Yes that's a transient issue I only ever tend to see on Travis. As such I've not managed to track it down to where it actually happens to add a retry in for that case.

[kinnison]

For the test, I'd be tempted to add the --allow-downgrade variant to the end of the longer test, so that the scenario plays out in full as:

1. Install
   2 Check for rls -- should not be present
2. Attempt to add rls -- this should fail
3. Attempt to add rls with downgrate permitted -- this should succeed
4. Check for rls -- should be present
5. Check hash for rustc -- should have downgraded

[kinnison]

Pretty close to mergeable -- some more test ideas. Nice job 👍

[kinnison]

Perhaps here add a check that the rls component is not installed You can do that with:

expect_component_not_executable(config, "rls");

[payload]

Although I added it I would rather see that in a different testcase which checks if toolchain install does not change anything without allow-downgrade. When I look at the subcommand toolchain install I see 7 arguments and would expect at least as many as 7 tests at the level of cli-v2.rs, but there are not. Or else I don't know yet about all the test levels. Well that's obvious :)

[kinnison]

After this, I'd add an expect to check the rustc version is the version we expect (i.e. one without rls)

[payload]

Yes, I add that. It is though like a sanity check to find out if our test setup is based on the right assumptions.

[kinnison]

While this is useful to check that it did downgrade, that'd be clearer if you'd done the equivalent above as commented. Also you could usefully assert that the rls component is now available via expect_component_executable()

[payload]

I like the expect_component_executable check much more than the version check. Thx

[kinnison]

This looks pretty good now. Could you please rebase to clean up the commits? I'd like to see a commit for the code and a commit for the tests at minimum. Once that's done, I'll give it a final once-over but I think this very close to mergeable

[payload]

@kinnison squashed it together. I have put the code change and its test together. When you split the test from the implementation it is less clear what belongs together. One reason to split test from implementation is of course to put the test before the implementation so you see the test failing first. Do you mean to put a separate test commit before the implementation commit?