Improve GrpcChannelFactory API

[onobc]

• Introduce a ChannelBuilderOptions that holds customizer, shutdownGracePeriod, and interceptors.
• Add type to GrpcChannelFactory and GrpcChannelBuilderCustomizer

[onobc]

@dsyer I believe this extended builder concept solves several of our current pain points.

Note

I bring the following point up now because it could impact the new extended channel builder design in this code proposal.

I noticed that the NettyChannelBuilder static methods handle the unix scheme, for example:

if (DOMAIN_SOCKET_ADDRESS_SCHEME.equals(address.getScheme())) {
    final String path = GrpcUtils.extractDomainSocketAddressPath(address.toString());
    return NettyChannelBuilder.forAddress(new DomainSocketAddress(path))
            .channelType(EpollDomainSocketChannel.class)
            .eventLoopGroup(new EpollEventLoopGroup());
} else {
    return NettyChannelBuilder.forTarget(address.toString())
            .defaultLoadBalancingPolicy(properties.getDefaultLoadBalancingPolicy());
}

1. Does the Grpc.newChannelBuilder() we are currently leveraging support unix scheme for Netty?
2. Refresh my memory why we did not have the createChannel return the specific ManagedChannelBuilder (e.g. NettyChannelBuilder)? Was it for simplicity?

[dsyer]

1. Does the Grpc.newChannelBuilder() we are currently leveraging support unix scheme for Netty?

At the time I wrote it I believed not (copied code from ecosystem), but looking at the UdsNameResolverProvider I'd say it probably does. Maybe there are some constraints related to customizing e-poll?

2. Refresh my memory why we did not have the createChannel return the specific ManagedChannelBuilder (e.g. NettyChannelBuilder)? Was it for simplicity?

I didn't want the user to have to know what kind of channel it is (same for servers). Mainly because I anticipated substituting the in-process version in tests. Maybe that was a bad decision - we'd have to support the in-process transport in a different way if we change the contract.

[dsyer]

LGTM. Maybe we should use the overloaded default factory method in the tests where possible though (no need for the second argument if it’s just the default)?