[FTR] Start dockerServers before ES & Kibana

[joshdover]

Today, the Functional Test Runner supports a dockerServers configuration key which allows a test config to specify a set of docker containers to start when running the test. This is used today by a few select test suites which depend on the Elastic Package Registry (EPR). Running a custom container rather than using the real registry service allow us to de-couple our tests from the real registry by serving up custom test packages for testing different scenarios. It also insulates Kibana's CI from operation or network issues with the live registry.

One of the key components that depends on this registry is Fleet's setup process, which will install a set of default packages (which is about to be removed in #108456) or installs packages as defined by the user in kibana.yml. In #111858, we switched to running this setup process on Kibana boot and in #120616, we plan to actually block Kibana's boot on successful completion of this Fleet setup process.

The problem with the current behavior of dockerServers is that it doesn't start the containers until the tests start executing, which means Fleet setup on boot currently fails with error messages like:

[system] could not be installed due to error: [RegistryConnectionError: Error connecting to package registry: request to http://localhost:12345/search?package=system&experimental=true failed, reason: connect ECONNREFUSED 127.0.0.1:12345]

Since this service is really a dependency of Kibana, it should be started before Kibana is booted. In the future, we expect ES may also have dependencies on this registry, so it would make sense to start it before ES as well.

The good news is that since we are removing the default package installs in #108456, this may be less of a pressing issue. However, we'd also like to add a test that emulates the kibana.yml behavior that is leveraged by our Cloud platform to install a default set of packages necessary to run that service (eg. APM and Fleet Server). Today, we can't do that due to the current dockerServers behavior which will cause Kibana to be unable to boot once we implement #120616.