Add a timeout for the backend stats collection query

[willmostly]

Add a timeout for the backend stats collection query.

Default the stats collection query to use EXECUTE IMMEDIATE by default, with the option to use explicit PREPARE if desired

Description

The stats collection query uses the traditional PREPARE/EXECUTE sequence to collect stats on the number of queued and running queries. There is a 10 second timeout on the PREPARE, however there is no timeout on the EXECUTE phase. This can cause issues on clusters that may be able to process the PREPARE quickly, but not the EXECUTE. This is configured as a Duration:

monitorConfiguration:
   queryTimeout: "10s"

In addition, the default mode has been updated to use EXECUTE IMMEDIATE to skip the prepare step. This has been available since 431. If needed to support earlier versions of Trino, explicit PREPARE can be enabled by setting:

monitorConfiguration:
   explicitPrepare: True

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

* Configure query timeout and use EXECUTE IMMEDIATE for backend stats collection

[oneonestar]

LGTM.

Just want to confirm my understanding. Is this correct?
explicitPrepare is True by default in Trino JDBC.
explicitPrepare is False by default in Trino Gateway.

[willmostly]

LGTM.

Just want to confirm my understanding. Is this correct? explicitPrepare is True by default in Trino JDBC. explicitPrepare is False by default in Trino Gateway.

@oneonestar your understanding is correct. Trino JDBC is being more conservative about preserving compatibility with older versions by default. I think it is a nice optimization since it reduces the number of health check queries by a factor of 2, and it has been available for >1 year now. But I could easily be convinced to default it to True if you think we should go the safe route

[oneonestar]

But I could easily be convinced to default it to True if you think we should go the safe route

Unlike clients, admins have full control over the version of Trino and Trino Gateway(and the JDBC driver embedded). I think it's okay to use 'False' as the default in the Trino Gateway. Maybe consider adding some docs.

[willmostly]

@oneonestar documentation added