Allow starting Elasticsearch container with VM options in query runner

[ebyhr]

Description

Allow starting Elasticsearch container with VM options in query runner

Documentation

(x) No documentation is needed.
( ) Sufficient documentation is included in this PR.
( ) Documentation PR is available with #prnumber.
( ) Documentation issue #issuenumber is filed, and can be handled later.

Release notes

(x) No release notes entries required.
( ) Release notes entries required with the following suggested text:

[martint]

This should be a proper argument to the query runner, not a magic system property

[ebyhr]

a proper argument to the query runner"

Do you mean passing as String[] args in the main method? The reason I used a system property is #3322 (comment)

[martint]

How is the server lifecycle managed? How does it get stopped?

[ebyhr]

The underlying container would be managed by Testcontainers ryuk. It will be closed with some delay when stopping the query runner.

[findepi]

We have some rudimentary support for "container reuse", which i think it what you're looking for.

I propose you use that, and let's avoid adding a yet new method of skipping container creation.

BTW, for manual testing, I find PT envs very useful. ptl env up .. --without-trino + DevelopmentServer is what i use locally. This requires no changes in the query runners. Of course, this works for manual testing, and doesn't work for running integration tests (those using QueryRunner), but i understand this is the use-case you're addressing here.

cc @kokosing @losipiuk

[findepi]

BTW starting ElasticsearchServer should actually be the default (and maybe the only) behavior of ElasticsearchQueryRunner::main

[martint]

I don’t think so. When I wrote that class and method, the goal was to be able to run Trino against an external ES instance so that I could try multiple different ES configurations (single node, a cluster, AWS ES, etc) as I was developing it. Hardcoding it defeats that purpose.

[findepi]

@martint i see your point, but that's not how QueryRunners.main are generally implemented.
They are self-contained first and foremost, and then re-usable if needed. I don't think ES should be special here.

[ebyhr]

How about adding another query runner for external service usage? Then, we can use ElasticsearchQueryRunner for dockerized environment.

public final class ElasticsearchExternalQueryRunner
{
    private ElasticsearchExternalQueryRunner() {}

    public static void main(String[] args)
            throws Exception
    {
        Logging.initialize();

        DistributedQueryRunner queryRunner = createElasticsearchQueryRunner(
                HostAndPort.fromParts("localhost", 9200),
                TpchTable.getTables(),
                ImmutableMap.of("http-server.http.port", "8080"),
                ImmutableMap.of(),
                3);

        Logger log = Logger.get(ElasticsearchExternalQueryRunner.class);
        log.info("======== SERVER STARTED ========");
        log.info("\n====\n%s\n====", queryRunner.getCoordinator().getBaseUrl());
    }
}

[findepi]

@ebyhr that sounds like a reasonable compromise.
in the ElasticsearchExternalQueryRunner please include a comment intructing hwo to start this external thing

[ebyhr]

@findepi @martint Added another query runner.

[findepi]

Use same version as one used in TestElasticsearch7ConnectorTest (define a constant)

[ebyhr]

Merged.

@martint You need to change IntelliJ run setting to use ElasticsearchExternalQueryRunner now.