Description
Transport implementations extend io.grpc.internal.AbstractManagedChannelImplBuilder to obtain most of their builder implementations. However, this leaks to the user in the Javadoc and with an api dependency in Gradle. The Javadoc in particular is a confusing mess because it isn't clear what is stable, experimental, and internal. Since we don't generate io.grpc.internal Javadoc and since the extending class "shadows" the base ManagedChannelBuilder, it also means the user is unable to click links to get to documentation for a large number of its methods. We should avoid extending AbstractManagedChannelImplBuilder in public (non-internal) classes.
To do this, we should extend ForwardingChannelBuilder instead (probably extending the Simple* version, which would need to be created). Transport implementations would create a AbstractManagedChannelImplBuilder and forward to it. We don't want to remove (useful) public methods in this process and break users, so we should make sure that there aren't any stray public methods in AbstractManagedChannelImplBuilder that would be dropped in the process.
The only abstract method in AbstractManagedChannelImplBuilder is buildTransportFactory(). We should probably inject that method in the constructor and convert the class to concrete, non-abstract. To simplify migration we can create ManagedChannelImplBuilder as a shim on top of AbstractManagedChannelImplBuilder. The shim could override some protected methods and make them public. It can also provide a setter for the checkAuthority override used by things like NettyChannelBuilder. Once all classes (external and internal) are migrated we can remove AbstractManagedChannelImplBuilder and combine it with the shim. If some classes still extend ManagedChannelImplBuilder that may be okay, but we should try to avoid such inheritance if possible.
The same should be done for AbstractServerImplBuilder.