Add Execute Immediate prepared statements support to JDBC

[lpoulain]

Description

Supports the use of EXECUTE IMMEDIATE when executing prepared statements. Adds a new JDBC boolean property LegacyPreparedStatements to control whether this feature should be used or not.

• Fixes Enhance the JDBC driver to use EXECUTE IMMEDIATE #18957

Additional context and related issues

By default, prepared statements requires to execute two queries and have the main SQL query passed back and forth between the client and the server three times. Those changes use Trino's recently introduced EXECUTE IMMEDIATE syntax which allows to execute a prepared statement with a single query.

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.
(X) Release notes are required, with the following suggested text:

# JDBC Driver
* Adds a new JDBC property `legacyPreparedStatements` which allows to control whether `EXECUTE IMMEDIATE` should be used to execute prepared statements

[aalbu]

Calling instance methods in a constructor can be dangerous, because the callee is an uninitialized object. Also, taking the hit for every connection may be undesirable. We should consider caching whether this capability is supported by a Trino instance at the class level. Or given the fact that support for EXECUTE IMMEDIATE has been available for a while now, perhaps we skip detection and turn it on by default. @hashhar , @findepi WDYT?

[electrum]

Since this is a fairly new feature in Trino, we should make this disabled by default. Users can opt-in, and we can make this a default in the future after it is better tested.

I don't think it makes sense to test this behavior, since the entire purpose is to reduce round trips. If the user is on an old version of Trino, they can disable this behavior in the driver.

[lpoulain]

Fair enough, code changed accordingly

[electrum]

Since this is a fairly new feature in Trino, we should make this disabled by default. Users can opt-in, and we can make this a default in the future after it is better tested.

I don't think it makes sense to test this behavior, since the entire purpose is to reduce round trips. If the user is on an old version of Trino, they can disable this behavior in the driver.

[hashhar]

cc: @wendigo since you were recently unifying TrinoUri and ConnectionProperties.

[lpoulain]

@electrum @hashhar would you mind reviewing the latest changes?

[hashhar]

mostly looks good, still trying to make sense of testLegacyPreparedStatementsSetting though.

[hashhar]

@lpoulain please rebase and resolve the conflict.

This looks good to go otherwise.

[lpoulain]

@hashhar rebased.

[nineinchnick]

CC @mosabua @colebow this needs docs

[mosabua]

@lpoulain are you sending a doc update PR?

[lpoulain]

@mosabua #19502 filed

[mosabua]

@electrum @dain @wendigo @hashhar and myself discussed this a bit more on slack. We need to get this refactored in terms of naming of the property. And maybe also default value.

Current suggested names are executeImmediate or explicitPrepare from @electrum but I will let you discuss all this more in the next PR to fix this. Lets also make sure the docs PR is updated.. or in fact you could collapse the docs and refactor into one PR .. whatever you prefer @lpoulain

[lpoulain]

@mosabua I can definitely update the doc PR to also modify the name of the property name. But the first step is to have an agreement on what should the new name be.