Describe the bug

We currently have a series of integration tests where our gRPC clients are tested using a Test Resource which provides the gRPC server. The resource returns a configuration map including the host and port configuration that the client should use.

I.e.

@Override public Map<String, String> start() { .... return Map.of( "quarkus.grpc.clients.the-grpc-service.host", "localhost", "quarkus.grpc.clients.the-grpc-service.port", "4444"); }

As of 3.3.0, we find our tests now fail as the gRPC client is attempting to connect to port 9001 instead of the port provided in the configuration returned by the test resource. Changes to host continue to work as before.
This appears to be due to the change in Channels.java: https://github.com/quarkusio/quarkus/pull/34135/files#diff-b0b8786ccab680283d88d8779d53044d5ea3e610284890ac7350e194be3629ca

At first glance this change appears to assume that the only time a gRPC client would be under integration test within a Quarkus application is when the application itself is providing the gRPC server/service and that it is thus safe to assume the port is that of the local gRPC server.

As of now, it appears our only option is to not integration test our grpc clients and introduce unit test mocks instead.

Expected behavior

Testing of gRPC clients within a Quarkus application should not assume the port of a local server is the correct port for the client.

Actual behavior

Integration tests of gRPC clients where the endpoint is not provided by the Quarkus application fail as the port is incorrectly forced to that of the local server.

How to Reproduce?

Create a QuarkusTest with a suitably implemented QuarkusTestResource that returns grpc client configuration containing a port.
Observe that the port is not used when the channel is created.

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

3.3.0

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

No response