remote-test-client tests mutate TEST_DEVICE_ADDR and break remote-test execution environments

Rust version: 1.93.0

Commit: https://github.com/rust-lang/rust/commit/444f1c534b03cd2fbd29521fafc332605d857b49

#[test]
fn test_timeout() {
    let mut cmd = assert_cmd::cargo::cargo_bin_cmd!();
    cmd.env("TEST_DEVICE_CONNECT_TIMEOUT_SECONDS", "1");
    cmd.env("TEST_DEVICE_ADDR", "127.69.69.69:6969");
    ...
}

We run rustc tests under a remote execution environment where remote-test-client is also
used as infrastructure (not just a tool under test).A real remote-test-server is running,
and TEST_DEVICE_ADDR is set globally by the test harness.

Environment:

• Tests executed via src/bootstrap/bootstrap.py test
• remote-test-server running on a target (QEMU)
• remote-test-client used by the test harness itself
• TEST_DEVICE_ADDR is set globally for all tests

When this mentioned testcase ran I got the below failure :

thread 'main' panicked at src/tools/remote-test-client/src/main.rs:332:9:
client.read_exact(&mut header) failed with failed to fill whole buffer

The panic occurs because the test modifies TEST_DEVICE_ADDR to an unreachable
value, causing the harness-level remote-test-client to disconnect mid-protocol.
The test mutates global environment variables used by the remote-test protocol,
which can interfere with other tests when remote-test-client is also active.

Possible fixes:

• Skip this test when TEST_DEVICE_ADDR is already set
• Run test_timeout with a sanitized environment
• Gate the test on a cfg flag or env var

Can we make this testcase is non-interfering in environments where
remote-test-client is active as infrastructure.

Maybe we can fix this test like below ?

 if std::env::var_os("TEST_DEVICE_ADDR").is_some() {
    eprintln!("Skipping test_timeout when TEST_DEVICE_ADDR is pre-set");
    return;
}

Start by locating the test_timeout test associated with src/tools/remote-test-client/src/main.rs and review how TEST_DEVICE_ADDR is set. Reproduce it with TEST_DEVICE_ADDR already defined under the bootstrap test environment. Done means the test no longer interferes with an active remote-test-client and its intended timeout behavior still passes.