Fix use-after-free in log handler teardown
Fix use-after-free in log handler teardown

Summary:
There's a use after free problem, similar to at least these [1](https://github.com/facebook/idb/commit/c60c3aaddc031db20c06c4b49b8d0f17b86bac3c#diff-2906e3c6b4a1664d371b1beb3dc10529e0c80c3c7a786a3d9c9509bf0b75f575) [2](https://github.com/facebook/idb/commit/91aa43c9ca05aa273d84c00cbef19e7a63549427#diff-2906e3c6b4a1664d371b1beb3dc10529e0c80c3c7a786a3d9c9509bf0b75f575) [3](https://github.com/facebook/idb/commit/ef44c5b1549c7bfa771f7ce85ef019ee72472e56#diff-2906e3c6b4a1664d371b1beb3dc10529e0c80c3c7a786a3d9c9509bf0b75f575) problems before. This one is similar.

The `context` object is passed in the gRPC handler and captured by a block that resolves continuously in the background. It polls on the `IsCancelled()` method. The handler thread can return before this block is called for the last time, in this case `context` is a dangling pointer and the companion can segfault.

In this change we ensure that:
1) If any write failed because the client went away any future data sent to the writer thread will short-circuit. This needs to happen as log data can be delivered after returning from the handler thread since it is delivered asynchronously.
2) The log operation is always torn down regardless of the outcome. This was previously leaking.
3) We prevent all future writing before returning from the handler thread.
4) In the handler, we sleep-loop to determine if the writing is done as well as if the RPC is cancelled. If it is cancelled, we can tear down and exit. The `context` object is now only ever looked whilst the handler is on the stack and running.

This should be enough to prevent crashers in log teardown from happening again.

Reviewed By: c-ryan747

Differential Revision: D29713410

fbshipit-source-id: 19be2671183bbd8bae3b26a969a56409866aaf52

facebook/FBSimulatorControl,facebook/FBSimulatorControl,facebook/FBSimulatorControl,facebook/FBSimulatorControl,facebook/FBSimulatorControl