Rollup merge of #96671 - mgeisler:current-exe-docstring, r=Mark-Simulacrum

Rollup merge of #96671 - mgeisler:current-exe-docstring, r=Mark-Simulacrum

Remove hard links from `env::current_exe` security example

The security example shows that `env::current_exe` will return the path used when the program was started. This is not really surprising considering how hard links work: after `ln foo bar`, the two files are _equivalent_. It is _not_ the case that `bar` is a “link” to `foo`, nor is `foo` a link to `bar`. They are simply two names for the same underlying data.

The security vulnerability linked to seems to be different: there an attacker would start a SUID binary from a directory under the control of the attacker. The binary would respawn itself by executing the program found at `/proc/self/exe` (which the attacker can control). This is a real problem. In my opinion, the example given here doesn’t really show the same problem, it just shows a misunderstanding of what hard links are.

I looked through the history a bit and found that the example was introduced in https://github.com/rust-lang/rust/pull/33526. That PR actually has two commits, and the first (https://github.com/rust-lang/rust/commit/8478d48dad949b3b1374569a5391089a49094eeb) explains the race condition at the root of the linked security vulnerability. The second commit proceeds to replace the explanation with the example we have today.

This commit reverts most of the second commit from https://github.com/rust-lang/rust/pull/33526.