Test Clusters integration test fails: time out waiting for cluster

[alpar-t]

https://elasticsearch-ci.elastic.co/job/elastic+elasticsearch+master+matrix-java-periodic/ES_BUILD_JAVA=java11,ES_RUNTIME_JAVA=java8,nodes=virtual&&linux/166/console

18:25:19       [myTestCluster][2019-01-07T16:25:15,527][INFO ][o.e.n.Node               ] [node-myTestCluster] initialized
18:25:19       [myTestCluster][2019-01-07T16:25:15,527][INFO ][o.e.n.Node               ] [node-myTestCluster] starting ...
18:25:19       [myTestCluster][2019-01-07T16:25:15,893][INFO ][o.e.t.TransportService   ] [node-myTestCluster] publish_address {127.0.0.1:40711}, bound_addresses {[::1]:46791}, {127.0.0.1:40711}
18:25:19       [myTestCluster][2019-01-07T16:25:15,937][WARN ][o.e.b.BootstrapChecks    ] [node-myTestCluster] the default discovery settings are unsuitable for production use; at least one of [discovery.zen.ping.unicast.hosts, discovery.zen.hosts_provider, cluster.initial_master_nodes] must be configured
18:25:19       [myTestCluster][2019-01-07T16:25:15,972][INFO ][o.e.c.c.ClusterBootstrapService] [node-myTestCluster] no discovery configuration found, will perform best-effort cluster bootstrapping after [3s] unless existing master is discovered

We will need to add the zen2 specific configuration that was done for ClusterFormationTasks in #36300 and #36398 to test-clusters.

[elasticmachine]

Pinging @elastic/es-core-infra

[DaveCTurner]

This looks like it's due to an overly enthusiastic timeout:

      [myTestCluster][2019-01-07T16:25:15,893][INFO ][o.e.t.TransportService   ] [node-myTestCluster] publish_address {127.0.0.1:40711}, bound_addresses {[::1]:46791}, {127.0.0.1:40711}
      [myTestCluster][2019-01-07T16:25:15,937][WARN ][o.e.b.BootstrapChecks    ] [node-myTestCluster] the default discovery settings are unsuitable for production use; at least one of [discovery.zen.ping.unicast.hosts, discovery.zen.hosts_provider, cluster.initial_master_nodes] must be configured
      [myTestCluster][2019-01-07T16:25:15,972][INFO ][o.e.c.c.ClusterBootstrapService] [node-myTestCluster] no discovery configuration found, will perform best-effort cluster bootstrapping after [3s] unless existing master is discovered
      [myTestCluster][2019-01-07T16:25:18,150][INFO ][o.e.x.m.p.NativeController] [node-myTestCluster] Native controller process has stopped - no new native processes can be started
      [myTestCluster][2019-01-07T16:25:18,178][INFO ][o.e.n.Node               ] [node-myTestCluster] stopping ...
      [myTestCluster][2019-01-07T16:25:18,181][INFO ][o.e.x.w.WatcherService   ] [node-myTestCluster] stopping watch service, reason [shutdown initiated]
      [myTestCluster][2019-01-07T16:25:18,871][INFO ][o.e.h.AbstractHttpServerTransport] [node-myTestCluster] publish_address {127.0.0.1:36373}, bound_addresses {[::1]:37821}, {127.0.0.1:36373}
      [myTestCluster][2019-01-07T16:25:18,873][INFO ][o.e.n.Node               ] [node-myTestCluster] started
      [myTestCluster][2019-01-07T16:25:18,874][INFO ][o.e.n.Node               ] [node-myTestCluster] stopped
      [myTestCluster][2019-01-07T16:25:18,874][INFO ][o.e.n.Node               ] [node-myTestCluster] closing ...

I.e. at 16:25:15,972 we say we're going to wait for 3 seconds and then bootstrap ourselves, similarly to how Zen1 works, and then the node is stopped before those 3 seconds have elapsed.

[alpar-t]

Recent slowness in CI probably also played a role and this just tipped it off.
But we need to have the same default with test-clusters anyhow.