Provide a way to create non-official gRPC client stub

Currently, Armeria gRPC client factory use reflections to find a stub factory method or constructor from the specified client type. Armeria supports well-known client types already such as gRPC-Java, Reactive-gRPC, gRPC-Kotlin, and so on.

When users want to use a new gRPC client stub with Armeria gRPC client, we need to add a new reflection code to find ServiceDescriptor and a stub factory. I think this is not scalable.

If we introduce a GrpcStubFactory, users can easily integrate their gRPC stub with Armeria.

interface GrpcStubFactory {
    // Should return a ServiceDescriptor to use gRPC JSON foramt
    @Nullable
    ServiceDescriptor serviceDescriptor();

    Object stub(Channel channel);
}

MyGrpcStub client = 
        Clients.builder(grpcUrl)
               .options(GrpcClientOptions.STUB_FACTORY.newValue(new GrpcStubFactory {
                    @Override
                    public ServiceDescriptor serviceDescriptor() {
                        return MyGrpcStub.SERVICE;
                    }

                    @Override
                    public Object stub(Channel channel) {
                        return MyGrpcStub.stub(channel);
                    }
               })
               .build(MyGrpcStub.class);

[trustin]

Does it look weird if we support both SPI and GrpcClientOptions.CLIENT_STUB_FACTORY? gRPC-Java, gRPC-Kotlin, Reactive gRPC, and ScalaPB can be provided by SPI.

I think that’s fine.

[ikhoon]

A generic type parameter could not be properly handled by SPI. In the following code, the IO type could be changed to other types by users’ choice.

GreetingServiceFs2Grpc.stub[IO](channel)

Does it look weird if we support both SPI and GrpcClientOptions.CLIENT_STUB_FACTORY? gRPC-Java, gRPC-Kotlin, Reactive gRPC, and ScalaPB can be provided by SPI.