[Ingest Manager] Use dockerized package registry in api integration tests

[skh]

Experimental

Implements elastic#61699

To run:

in the x-pack directory, run:

$ export INGEST_MANAGEMENT_PACKAGE_REGISTRY_PORT=12345
$ node scripts/functional_tests_server.js --config test/epm_api_integration/config.ts

In the main kibana directory, run

$ export INGEST_MANAGEMENT_PACKAGE_REGISTRY_PORT=12345
$ node scripts/functional_test_runner.js --config x-pack/test/epm_api_integration/config.ts

Port 12345 is used as an example here, it can be anything, but the environment variable has to be present for the tests to run at all.

Changes

• Adds args to DockerServerSpec which are passed through to docker run. These have to be arguments to docker run, not to the whatever is run in the docker container.
• Adds a test that uses the DockerServerService to x-pack/test/epm_api_integration and disables all other tests in that directory for now (These aren't currently run in CI, see [Ingest Manager] Rename and re-enable EPM api integration tests elastic/kibana#67943).
• Removes the docker container after the test is run. Without this, docker containers pile up locally, check with docker ps -a.
• Removes the DockerServerService configuration / setup from x-pack/test/functional for now.

Open questions

• Maybe there should also be a way to pass through arguments to the executable in the docker container. I didn't need it for now, but I could imagine someone would soon.
• Currently docker run is started once per test lifecycle, which corresponds to a config.{js,ts} file setting up the tests (?). It might be beneficial to be able to start and stop the dockerized executable from the tests themselves with different sets of arguments. That way, we could e.g. move the test fixtures closer to the tests themselves, and have finer granularity overall.
• How big are docker images used in these tests allowed to be? The package registry is currently around 400MB (https://container-library.elastic.co/r/package-registry/package-registry:master). As we use a local directory to serve the packages from, we could build a smaller image with no packages in it. However, if other parts of Kibana want to enable ingest manager during tests, it's maybe good to have a set of known-good packages to be served by default.
• Should we continue to create plugin-specific test configurations (i.e. subdirectories with their own config.{ts,js} in them) or should we strive to move them to the 'common' test directories and add complexity to their setup? (This would be easier if starting the dockerized executable with different arguments was possible from within the tests, instead of the overall configuration, see above.)
• How can a test be skipped when the DockerServersService couldn't be set up successfully, e.g. because process.env.INGEST_MANAGEMENT_PACKAGE_REGISTRY_PORT wasn't set?

[skh]

@spalger This is worth a look now.

[spalger]

This is awesome, I think I'm going to reformat the way we're working on this project so that the core functionality is implemented in a branch on elastic/kibana and the tests are implemented in another PR so that we can keep the files changed small enough for human brains :)

I'll bring your questions into the new PR I setup as I don't think there are obvious answers and I think we should keep the discussion in elastic/kibana.