Rollup merge of rust-lang#127246 - ferrocene:hoverbear/remote-test-cl…

…ient-has-longer-timeout, r=Mark-Simulacrum

Give remote-test-client a longer timeout

In rust-lang#126959, ``@Mark-Simulacrum`` suggested we simply extend the timeout of the `remote-test-client` instead of making it configurable. This is acceptable for my use case.

I'm doing some work with a remote host running tests using `x.py`'s remote test runner system.

After building the `remote-test-server` with:

```bash
./x build src/tools/remote-test-server --target aarch64-unknown-linux-gnu
```

I can transfer the `remote-test-server` to the remote and set up a port forwarded SSH connection, then I run:

```bash
TEST_DEVICE_ADDR=127.0.0.1:12345 ./x.py test library/core --target aarch64-unknown-linux-gnu
```

This works great if the host is nearby, however if the average round trip time is over 100ms (the timeout), it creates problems as it silently trips the timeout.

This PR extends that timeout to a less strict 2s.

r? ``@Mark-Simulacrum``

src/tools/remote-test-client/src/main.rs

@@ -71,7 +71,7 @@ fn spawn_emulator(target: &str, server: &Path, tmpdir: &Path, rootfs: Option<Pat
 
     // Wait for the emulator to come online
     loop {
-        let dur = Duration::from_millis(100);
+        let dur = Duration::from_millis(2000);
         if let Ok(mut client) = TcpStream::connect(&device_address) {
             t!(client.set_read_timeout(Some(dur)));
             t!(client.set_write_timeout(Some(dur)));