Put testing with with JDK 20 on hold

[findepi]

We observed CI instability with 20. We should reintroduce testing with 20 in a way that doesn't break the CI builds.

Motivation / context: #16933 (comment)
stress test on the CI with further evidence: #17490

Hopefully fixes #16987
Hopefully fixes #16933

[martint]

Java 19 is EOL. There’s no point in testing with that version anymore.

[findepi]

That's the newest version we didn't observe tests flakiness with. Removing all testing with any Java newer than 17 isn't desirable, as it would allow merging some code that no longer works with newer Java version. See for example #15709.

I don't feel strongly about this though, I can skip re-adding 19.

[martint]

We observed CI instability with 20. We should reintroduce testing with 20 in a way that doesn't break the CI builds.

How would we do that? We need to be able to test with 20 (and later this year, with 21), as we’re planning to move to those versions to be able to take advantage of new APIs.

Also, how certain are we that the instability is due to Java 20 and not some other factor?

[wendigo]

@martint pretty certain. 19 is stable, 20 flaky regardless of the distribution (azul, temurin)

[martint]

Can you try disabling OptimizeStringConcat? (by setting -XX:-OptimizeStringConcat)

[martint]

Also, try with a version of QueryId.parseDottedId() that prints more details when the expected condition is not met:

checkArgument(ids.size() == expectedParts, "Invalid %s %s", name, id);

checkArgument(ids.size() == expectedParts, "Invalid %s %s, ids = %s, expectedParts = %s", name, id, ids, expectedParts);

[findepi]

i think i already did enough to warrant what's a logical revert of #16676.
we have flaky master, trino-main, we have evidence that this is due to JDK 20.
i don't have anything against diagnosing what's the problem with 20, but regardless of our ambitions in this regard, we should merge this first.

Also, how certain are we that the instability is due to Java 20 and not some other factor?

#17490