[Fleet] Remove EPR container from FTR tests

[joshdover]

As per discussion in #116591 (comment), we believe we no longer need the EPR container for running functional tests due to the fact that we are now bundling all packages that we have tests for in the Kibana suite.

We should remove this from all test suites and rely on the bundled packages instead.

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[joshdover]

#129367 needs to be solved before we can remove the EPR image

[joshdover]

• If we removed the Docker image, we wouldn't be able to run tests against the registry on our custom test packages and would need to upload all these test packages
• This limits our ability to test code paths that are specific to registry packages (vs. bundled/uploaded packages). We should identify these codepaths and see if we need/want to test these with functional tests or if unit tests would be sufficient.

[ruflin]

Lets assume for a moment all tests packages and bundled packages are in Kibana. So for testing these packages, the registry is not needed anymore. But that still means we don't do any tests against the actual registry / most recent changes of the registry. I think of this similar to testing against SNAPSHOT of Elasticsearch except that in the registry scenario it is very likely a version that is already out there. In the early days of the package-registry, there were breaking changes between minors and the package-registry tests made Kibana fail. So the container + specific version was attached to Kibana. The package-registry is now stable and breaking the API is not an option as it needs to be compatible with older versions of Kibana. If any package-registry change broke Kibana, we should know ASAP.

There are several ways on how to solve this:

• Kibana tests against the most recent released version of the registry (epr.elastic.co). Not ideal because of potential network issues and it means only after a release potential issues are uncovered
• Kibana bundles a container with the registry: Same as we do today, but instead of using a distribution a registry could be built only with the minimal packages. This means updates only happen when the registry changes, not when packages are added (it is possible we have something similar already today)
• E2E test suite: Instead of adding it to Kibana itself, an e2e test suite covers the integration with the registry.

I expect we already e2e tests in place that covers this but I'm in favour of option 2. Kibana (Integrations / Fleet) by now considers the registry to almost always be there. If we have registry, someone creating tests against certain packages can just do it. Today the hash we test against is hardcoded. This is to ensure reproducible builds. Instead of manually updating the registry when changes happens, this should happen each time a PR to package-registry are merged (do we also need to consider package-spec). The current version of the package-registry is 1.8.0 and the next upcoming is 1.8.1. As soon as 1.8.0 is released and the version in the package-registry is updated, a pull request against Kibana would be opened to test against docker.elastic.co/package-registry:1.8.1-SNAPSHOT (name shortened). This change should be done to all active development branches also 7.17 for example to ensure it stays compatible there. Then the Fleet team needs to review these PRs. We could go further and have a hash instead of SNAPSHOT to make it even more precise (likely better).

Having this would mean:

• We test bundled packages
• We can test installing packages from the registry, these packages would ahve to be versioned in Kibana and loaded into the registry
• We test against the latest version of the registry

My understanding is that so far this docker setup for the registry did not really cause issues?