Make concurrent insert timeout adjustable for testInsertRowConcurrently

[vlad-lyutenko]

Description

Most often we experienced this test failing due to timeout waiting on the barrier,
the reason behind this for pooled connectors is connection timeout,
making this timeout adjustable according to connection timeout settings

.testInsertRowConcurrently()[2] -- Time elapsed: 30.63 s <<< ERROR!
2025-11-28T18:46:32.1530648Z java.lang.RuntimeException: Wait timed out
2025-11-28T18:46:32.1532348Z 	at io.trino.testing.BaseConnectorTest.lambda$testInsertRowConcurrently$3(BaseConnectorTest.java:5500)
2025-11-28T18:46:32.1533985Z 	at java.base/java.util.Optional.orElseThrow(Optional.java:403)
2025-11-28T18:46:32.1535456Z 	at io.trino.testing.BaseConnectorTest.lambda$testInsertRowConcurrently$2(BaseConnectorTest.java:5500)
2025-11-28T18:46:32.1537311Z 	at java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:214)
2025-11-28T18:46:32.1539043Z 	at java.base/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:1024)
2025-11-28T18:46:32.1540712Z 	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:570)
2025-11-28T18:46:32.1542454Z 	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560)
2025-11-28T18:46:32.1544144Z 	at java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:921)
2025-11-28T18:46:32.1545724Z 	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:265)
2025-11-28T18:46:32.1547371Z 	at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:723)
2025-11-28T18:46:32.1549131Z 	at io.trino.testing.BaseConnectorTest.testInsertRowConcurrently(BaseConnectorTest.java:5503)
2025-11-28T18:46:32.1550727Z 	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
2025-11-28T18:46:32.1552289Z 	at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:328)
2025-11-28T18:46:32.1553921Z 	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1090)
2025-11-28T18:46:32.1555708Z 	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
2025-11-28T18:46:32.1557191Z 	at java.base/java.lang.Thread.run(Thread.java:1474)

Additional context and related issues

Release notes

( ) This is not user-visible or is docs only, and no release notes are required.
( ) Release notes are required. Please propose a release note for me.
( ) Release notes are required, with the following suggested text:

## Section
* Fix some things. ({issue}`issuenumber`)

[findepi]

Most often we experienced this test failing due to timeout waiting on the barrier,
the reason behind this for pooled connectors is connection timeout,

Or are we witnessing lockup because we're using more threads than the pool size?

[vlad-lyutenko]

Or are we witnessing lockup because we're using more threads than the pool size?

I experienced this issue also for slow connectors with pool size bigger then amount of threads (so when metadata calls tooks some time e.t.c)

[findepi]

Maybe this test is more problems than it's worth....

[findinpath]

@vlad-lyutenko pls add 1 or more stacktrace in the description of the issue to relate better to the changes you're doing in this contribution. 🙏