binder: Cross-process calls against a shutdown() Server do not fail fast as required by AbstractTransportTest

[jdcormie]

What version of gRPC-Java are you using?

master

What is your environment?

Android/Linux

Steps to reproduce the bug

1. Declare an Android Service hosting an BinderServerBuilder-built Server in process A
2. In a second process B, create an BinderChannelBuilder-built Channel to that Server and send a call that completes successfully. This causes the Service to be bound and a Server to be created.
3. Invoke Server#shutdown() in A
4. In a process other than A, create a second BinderChannelBuilder-built Channel to the Server and send a call with no deadline.

What did you expect to see?

According to AbstractTransportTest#serverNotListening(), a ManagedClientTransport start()ed after its Server is shutdown() should report transportShutdown(UNAVAILABLE) within 5 seconds. Based on this, I expect that a new call to a shutdown()-but-otherwise-healthy Server would fail quickly.

What did you see instead?

The second call hangs forever.

Discussion

The second BinderClientTransport's call to bindService() succeeds, returning Android's cached copy of "hostServiceBinder" without any interaction with process A. Because client and server are in different processes, the second BinderClientTransport's call to transact(SETUP_TRANSPORT, ... FLAG_ONEWAY) is dispatched asynchronously -- it returns true immediately but, later on the server, LeakSafeOneWayBinder#onTransact() returns without processing the transaction because it has been detach()ed by shutdown(). The second BinderClientTransport is stuck waiting for a SETUP_TRANSPORT reply that will never come.

AbstractTransportTest#serverNotListening() only passes today because client and server are in the same unit test process, making the client's LeakSafeOneWayBinder#onTransact's call synchronous and giving the client immediate feedback about its failure.

[jdcormie]

@markb74 Any ideas on how to handle this?