If the frame handler thread is null do not schedule it on the executor

[kannanjgithub]

Fixes NPE from "Detect transport executors with no remaining threads #11503".

[ejona86]

I think the latch/barrier handling needs to move into the try-catch that guarantees clientFrameHandler is set. So if the second thread fails, we'll use the source with "Use closed source on failure so that the reader immediately shuts down."

[kannanjgithub]

Only the source is guaranteed to be set after a certain point, so I think you mean source and not clientFrameHandler. I have pushed a commit with an attempt, although some other tests need fixing that fail with a NPE.

[ejona86]

Assigning clientFrameHandler is part of a finally block.

grpc-java/okhttp/src/main/java/io/grpc/okhttp/OkHttpClientTransport.java

Lines 593 to 594 in a431e36

	} finally {
	clientFrameHandler = new ClientFrameHandler(variant.newReader(source, true));

[kannanjgithub]

The case causing NPE for clientFrameHandler is this latch.await() timing out and sending a go away for internal error. How could this code be moved after clientFrameHandler is initialized in finally, because I thought we had to wait for connection preface settings to be sent first.

[ejona86]

Move it into the try block, so if it fails clientFrameHandler will be initialized still via the finally.

[kannanjgithub]

Got it, I wrongly assumed you were implying changing the order of the statements and got confused, you were only suggesting expanding the try scope to include the latch and barrier await. Pushed the commit.