[Testing] increase orca oob test timeout (#33098)

each oob test runs at least 2s (2 verifications with each server sending
report each 1s), current configuration allows at most 3 clients run in
parallel. In reality, probably only the two clients against one server.
Currently 8 jobs are running each batch, and it happens that each batch
has at most 2 oob clients against one server.
Since 3 languages support orca, so we should allow 3 clients running
against one server so the timeout is at least 4s. We give some buffers
to allow tests running more reliably.
10s in theory support 5-6 clients running against one server.

doc/interop-test-descriptions.md

@@ -1152,12 +1152,12 @@ Procedures:
       }
     }
     ```
-2. After getting a response, client waits up to 5 seconds to receive a OOB load 
-report that matches the requested load report in step 1. To wait for load 
-report, client may inject a callback to the custom LB policy, or poll the result
-by doing empty unary call that carries a reference, e.g. using 
-CallOptions, that will be filled in by the custom LB policy as part of the 
-`OrcaOobReportListener` API.
+2. After getting a response, client waits up to 10 seconds (or a total of 30s
+for the entire test case) to receive an OOB load report that matches the
+requested load report in step 1. To wait for load report, client may inject a
+callback to the custom LB policy, or poll the result by doing empty unary call
+that carries a reference, e.g. using CallOptions, that will be filled in by the
+custom LB policy as part of the `OrcaOobReportListener` API.
 3. Then client sends: 
     ```
     {
@@ -1173,8 +1173,9 @@ CallOptions, that will be filled in by the custom LB policy as part of the
       }
     }
     ```
-4. After getting a response, client waits up to 5 seconds to receive a OOB load
-report that matches the requested load report in step 3. Similar to step 2.
+4. After getting a response, client waits up to 10 seconds (or a total of 30s
+for the entire test case) to receive an OOB load report that matches the
+requested load report in step 3. Similar to step 2.
 5. Client half closes the stream, and asserts the streaming call is successful. 
 
 ### Experimental Tests