ClientCalls.ThreadlessExecutor should reject Runnables after end of RPC

[ejona86]

As seen in #3537, the executor was being used for multiple RPCs which caused some Runnables to be queued but never run. We are in a position to know they will never execute though, so it'd be nice to have a (possibly unreliable) detection of rejected Runnables to notice issues like this earlier.

This could be accomplished with just a volatile shutdown boolean that is checked before execute() and a shutdown() method. That's racy, but we're just wanting it to detect bugs, not provide correctness.

[ejona86]

Note: this is made more complicated by grpc's current handling of application exceptions (centering around closed), as we deliver an application exception immediately back to the application in close(), but the transport trails behind and can continue scheduling work. This was done to provide a clean set of callbacks to the application. It would be possible to cancel the RPC, then wait (by short-circuiting Runnables) for the close() to arrive, although we'd then need to replace the Status with the cancellation (vs using a status possibly from the server, which we can't give to the user, since it is out-of-context if we chose not to deliver messages).

[ejona86]

With #7187 and #7457, to my knowledge we are no longer scheduling runnables after onClose().

[ejona86]

Reverted by #7920. It found a bug!