Append `~/.rustup/toolchains/bin` to PATH when running a proxy

Problem you are trying to solve

I am writing a new rustc_driver tool (say it's called foo). I want to be able to have multiple versions, so I've put it in the toolchain directory instead of the per-user ~/.cargo/bin (which only allows a single version). Additionally, I want to be able to run it as cargo +nightly foo, so I have a cargo-foo binary which works like cargo-clippy, setting RUSTC_WORKSPACE_WRAPPER.

90% percent of this already works. cargo +nightly foo runs the rustup proxy, which sets RUSTUP_TOOLCHAIN and runs the correct version of cargo, which calls cargo-foo. Here's the problem: cargo-foo is not actually in PATH. It's in /Users/jyn/.local/lib/rustup/toolchains/stage1/bin/cargo-foo, not ~/.cargo/bin. To make this work, I have to write a third cargo-foo binary to go in ~/.cargo/bin and dispatch based on RUSTUP_TOOLCHAIN.

Solution you'd like

It would be really nice if rustup would add /Users/jyn/.local/lib/rustup/toolchains/stage1/bin to PATH so that I don't need to write this third binary. That would make it fully scoped to the toolchain directory so there's no global setup needed and I don't have to worry about differences between the proxy in different versions.

Notes

Unfortunately, this has caused issues in the past; https://github.com/rust-lang/rustup/pull/3178 has a very good writeup. I think as long as we always append the directory to the path, so that it's only used if there's no proxy in ~/.cargo/bin, this should work ok, but it's a complicated space.

Start by reading the issue and rustup#3178, which documents prior problems with changing PATH from a proxy. Trace the proxy behavior described here and determine how an appended toolchain bin directory would preserve existing ~/.cargo/bin precedence. Done means the behavior works for toolchain-scoped cargo subcommands without requiring a global wrapper.