Testclusters: implement starting, waiting for and stopping single cluster nodes

[alpar-t]

The bulk of the request is new functionality in ElasticsearchNode.
Note that this offers 0 configuration, this ability will be added as we start to use testclsuters and find a need for things to be configurable to keep these to a minimum.
My thinking is that we can auto configure in some of the cases where we have configuration for cluster-formation ( e.x. detect that security is installed and do the right checks automatically).

The accompanying tests are still the only users of this functionality.

A quick map to help navigate the PR:

• setting up a directory layout and writing config file writeConfigurationFile
  • we don't copy the entire distribution, only the config folder and create folders in a different location to store data, logs, etc.
• We start the process with ProcessBuilder and redirect the streams to files start
  • There are cleanup hooks to make sure processes started by the build won't outlive it registerCleanupHooks
• Stopping the cluster stops all processes with the same api in stop and reads the files into the stream on failure.
• We wait for the cluster to be ready only when and each time we get a request for it's address. There's a generic mechanism to deal with waiting, but it's not configurable for now.

Tests are passing on Windows.

[elasticmachine]

Pinging @elastic/es-core-infra

[alpar-t]

Thanks for the review @original-brownbear ! I left some answers.

[original-brownbear]

@atorok thanks! Looks good in general :), but see my comment about the thread leak.

[alpar-t]

I moved the cleanup of processes outside of ElasticsearchNode I think it's a better fit for the plugin, and this also takes care to make sure the thread is not leaked in the daemon.

[alpar-t]

@nik9000 can you take another look please.

[nik9000]

I'm happy with this. I think it pushes the project forwards and i like it. I think there are a couple of unrelated changes bundled up in it. At least, I can't see how they are related. Could you explain them? Or maybe move them into their own PR so they get a nice commit message explaining them?

[alpar-t]

@nik9000 I should have offered more details on these changes . I now realize they seem out of place. They do need to be part of this PR.
In #34746 I moved buildSrc to target java 10 ( 11 doesn't work with gradle 4.10 ) but this is the first change that actually uses something newer than java 8. Turns out my previous change was incomplete as it changed buildSrc but not build-tools because the build plugin was setting it back to 8 so we need to be specific about it again after applying the plugin. I'll look to clean up the package naming change, that's unintentional.

[alpar-t]

@nik9000 we do also need to run the naming convention check with the compiler java as build-tools how has classes for newer java versions. We could do it locally for build tools only but it doesn't matter much since we'll be using compiler java for this check with testingConventions soon anyhow.

[alpar-t]

@elasticmachine run gradle tests 1

[alpar-t]

@elasticmachine run gradle build tests 1

[alpar-t]

@nik9000 I double checked to be sure. All comments on the PR should be addressed.

[alpar-t]

@elasticmachine run default distro tests

[alpar-t]

@elasticmachine run default distro tests