The actual RPC timeout is cut in half wrt the expected value by a bug introduced in D9232.
The rpc proxy has its timeout cut in half to allow for one retrty should the timeout trigger, because the outer loop is accounting for the whole timeout value. The issue is that this rpc proxy is then assigned as is to the TestNode instance, so all the subsequence RPC calls will also use a halved timeout.
This behavior can be seen in this CI failure, where the generate call times out after 120s despite the test being configured to use a 240s timeout: https://build.bitcoinabc.org/viewLog.html?buildId=606879&guest=1

The fix is to loop during twice the timeout instead of cutting the timeout in half. This have no performance impact under normal circumstances and will only wait for longer before failing if there is an issue, which is less of a problem than having a flaky test due to a misconfigured timeout.