NativeImageTest with container-image extensions

[snowdrop-bot]

Description

When using:

• quarkus.native.container-build=true (GraalVM/Mandrel native-image used from a docker image during NativeImageBuildStep)
• and quarkus.container-image.build=true (the application native executable is dockerized by JibProcessor)

it would be great if @NativeImageTest would be able to actually use that docker image to start the application, rather than trying to start the native executable inside/target from NativeImageBuildStep, because it may fail to start if incompatible with the host OS (i.e. building a Linux executable on a Windows laptop).

<properties>
  <quarkus.package.type>native</quarkus.package.type>
  <quarkus.native.container-build>true</quarkus.native.container-build>
  <quarkus.native.container-runtime>docker</quarkus.native.container-runtime>
  <quarkus.container-image.build>true</quarkus.container-image.build>
  <quarkus.container-image.push>false</quarkus.container-image.push>
</properties>
<dependencies>
  <dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-container-image-jib</artifactId>
  </dependency>
</dependencies>

This is also somehow related to quarkusio#8654

Implementation ideas

I don't know if it is technically feasible for container-image-* extensions to change the behavior of NativeImageTest, which is core.
NativeImageLauncher might use TestContainers to start the containerized native image if quarkus.container-image.build build=true, rather than trying to launch the xxx-runner native executable ?
It would look for the image built during package phase, retrieving it from the docker daemon or the docker registry (depending on value of quarkus.container-image.push).

---

quarkusio#13818

---

$upstream:13818$