Great work! The code is easier to understand.

Reviewed 15 of 15 files at r1.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @apolcyn and @markdroth)

src/core/ext/filters/client_channel/lb_policy.h, line 105 at r1 (raw file):

    /// An interface for accessing call state.  Can be used to allocate
    /// data associated with the call in an efficient way.
    CallState* call_state;

This should be initialized to null.

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @apolcyn and @AspirinSJL)

src/core/ext/filters/client_channel/lb_policy.h, line 105 at r1 (raw file):

I don't think that's necessary, since it will be set unconditionally by the channel.

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @apolcyn and @markdroth)

src/core/ext/filters/client_channel/client_channel.cc, line 1337 at r1 (raw file):

  }
  LoadBalancingPolicy::PickResult result =
      picker_->Pick(LoadBalancingPolicy::PickArgs());

But here we don't get call_state initialized?

src/core/ext/filters/client_channel/lb_policy.h, line 105 at r1 (raw file):

It seems uninitialized in DoPingLocked().

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @apolcyn, @AspirinSJL, and @markdroth)

src/core/ext/filters/client_channel/lb_policy.h, line 105 at r1 (raw file):

Yeah, but I'm not worried about that. That code-path is only ever executed from tests; there is no public API by which users can trigger it. And the tests that use it only use pick_first, and we know that pick_first doesn't use call state object.

Basically, the ping code-path is kind of a hack for tests and not very well supported anyway, so I don't feel the need to provide any real guarantees about the API in that case.