[jMd3ZuqI] Fix arrow flaky tests

[ncordon]

What

Uses just one thread in the arrow export procedures to fix flaky tests:

java.lang.ArrayIndexOutOfBoundsException: Index 0 out of bounds for length 0
    at org.eclipse.collections.impl.set.strategy.mutable.UnifiedSetWithHashingStrategy.copyBucketToArray(UnifiedSetWithHashingStrategy.java:1732)
    at org.eclipse.collections.impl.set.strategy.mutable.UnifiedSetWithHashingStrategy.copyToArray(UnifiedSetWithHashingStrategy.java:1718)
    at org.eclipse.collections.impl.set.strategy.mutable.UnifiedSetWithHashingStrategy.toArray(UnifiedSetWithHashingStrategy.java:1767)
    at java.base/java.util.Collection.toArray(Collection.java:413)
    at org.neo4j.kernel.impl.api.CloseableResourceManager.closeAllCloseableResources(CloseableResourceManager.java:62)
    at org.neo4j.kernel.impl.api.KernelStatement.cleanupResources(KernelStatement.java:247)
    at org.neo4j.kernel.impl.api.KernelStatement.close(KernelStatement.java:128)
    at org.neo4j.kernel.impl.query.Neo4jTransactionalContext.closeStatement(Neo4jTransactionalContext.java:161)
    at org.neo4j.kernel.impl.query.Neo4jTransactionalContext.close(Neo4jTransactionalContext.java:150)
    at org.neo4j.cypher.internal.runtime.interpreted.SingleThreadedTransactionalContextWrapper.close(TransactionalContextWrapper.scala:135)
    at org.neo4j.cypher.internal.runtime.interpreted.DelegatingQueryTransactionalContext.close(DelegatingQueryContext.scala:747)
    at org.neo4j.cypher.internal.planning.ExceptionTranslatingReadQueryContext$ExceptionTranslatingTransactionalContext$.close(ExceptionTranslatingQueryContext.scala:546)
    at org.neo4j.cypher.internal.CypherCurrentCompiler$CypherExecutableQuery.$anonfun$execute$2(CypherCurrentCompiler.scala:393)
    at org.neo4j.cypher.internal.result.StandardInternalExec...

Why

Because if we have two threads, if one of the threads frees the result stream that the outer one owns (this happens when there are not any more elements in the stream), the outer transaction thread might not see that change (https://stackoverflow.com/a/2787581). This could be the cause why we are experiencing some flakiness.

It makes sense to change the code anyway because it is really convoluted and there's no reason why we need a new transaction in another thread.

We should review the use of that QueueSplitIterator everywhere.

[gem-neo4j]

This was a nice cleanup to see :D Can you make a card for the cleanup of QueueSplitIterator in general?

[ncordon]

/spotlessApply