Rustup proxies not longer working with symlink resolution since 1.28.0

Verification

• I searched for recent similar issues at https://github.com/rust-lang/rustup/issues?q=is%3Aissue+is%3Aopen%2Cclosed and found no duplicates.
• I am on the latest version of Rustup according to https://github.com/rust-lang/rustup/tags and am still able to reproduce my issue.

Problem

coming from this report: https://github.com/rust-lang/rustwide/issues/94 , currently docs.rs builds are broken because of this issue.

There seems to be something wrong with the symlinks that are now generated instead of hardlinks for the binaries (https://github.com/rust-lang/rustup/pull/4023).

We are using fs::canonicalize before passing it to the binaries:
https://github.com/rust-lang/rustwide/blob/744375a9050e0584124ea11adaeab41781fa8a50/src/utils.rs#L111-L112

Steps

What information would you need to be able to track this down?

we can reproduce it when just trying to run any docs.rs build,

the two errors I saw where both just showing that the call does to rustup install instead of cargo install (or other calls to cargo are done on rustup)

Possible Solution(s)

No response

Notes

No response

Rustup version

1.28.0

Installed toolchains

it happens with just one toolchain installed, tested with `stable-aarch64-apple-darwin` or `stable-x86_64-unknown-linux-gnu`

OS version

Ubuntu 18.04.2 LTS on the server, or newer ubuntu in docker images

Start by reproducing a docs.rs build with rustup 1.28.0 and inspect rustwide's src/utils.rs around lines 111-112, where fs::canonicalize is used. Compare the symlink behavior introduced by rustup PR 4023 and verify that cargo and other tool calls no longer resolve to rustup instead; done means the reported docs.rs builds work again.