Error "Unable to read from stream socket" in UDP reverse mode on iperf3 client

# Context
I am using iperf3 in a product that tests the UDP data throughput of mobile networks.
Sometimes the iperf3 client fails at the beginning of the UDP transfer in reverse mode and reports the message
`iperf3: error - unable to read from stream socket: `

Versions of iperf3:
on the iperf client side: 3.16
on the iperf server side: 3.17

Hardware:
on the iperf client side: Samsung A52s
on the iperf server side: Server with Intel(R) Xeon(R) Platinum 8259CL CPU @ 2.50GHz

Operating system:
on the iperf client side: Android 11
on the iperf server side: Ubuntu 22.04.4 LTS

# Bug Report
Expected Behavior:
The client should not fail.

Actual Behavior:
The iperf3 client fails at the beginning of the UDP transfer in reverse mode.

The iperf3 client command (on the Android phone) is:
iperf3 --forceflush -c x.x.x.x -V -p 5208 -u -t 15 -i 5 -fK -4 -b 62500000 -l 1200 -P 4 -O 0 -R
(x.x.x.x is the IP address of the server)

Here below the iperf3 log in case of failure:
```
iperf 3.16
Linux localhost 5.4.86-qgki-22775054-abA528BXXU1AUK4 #1 SMP PREEMPT Fri Nov 5 16:50:52 KST 2021 aarch64
Control connection MSS 1298
Time: Mon, 17 Feb 2025 19:53:11 GMT
Connecting to host 83.103.115.246, port 5208
Reverse mode, remote host xxx.xxx.xxx.xxx is sending
Cookie: o4kkpwwwof64csuhsr3nv2buvzdbyink34vj
Target Bitrate: 62500000
[ 5] local 10.115.179.92 port 35305 connected to xxx.xxx.xxx.xxx port 5208
[ 7] local 10.115.179.92 port 42010 connected to xxx.xxx.xxx.xxx port 5208
[ 9] local 10.115.179.92 port 45951 connected to xxx.xxx.xxx.xxx port 5208
iperf3: error - unable to read from stream socket:
```

Steps to Reproduce:
It's not easy to reproduce this issue, as it depends on the state of the network connection.

The issue is not systematic and happens in case of congested data connection (iperf3 client is an Android phone with a LTE connection).

Here is the IP log:
[TcRun_701281459_1_O_IP.Log.zip](https://github.com/user-attachments/files/19180362/TcRun_701281459_1_O_IP.Log.zip)

From the IP log, it appears that the iperf3 client did not receive a response to the start request for some UDP streams and therefore it fails.
The server receives all requests and starts all four streams. In fact, the IP log shows that the client also receives the streams that were not acknowledged.
Therefore, theoretically, the Iperf3 client could understand that the stream was started but that it lost the first packets.

UDP transfer is not reliable, and therefore some packets may be lost. If the first packets are lost, Iperf3 should tolerate the loss and continue instead of failing.