This fixes some TODOs added in #30809 for cases where LB policies lazily create child policies. Credit to @ejona86 for pointing out that simply calling `RequestReresolution()` in this case will ultimately result in the exponential backoff behavior we want.
This also adds some missing plumbing in code added as part of the dualstack work (in the endpoint_list library and in ring_hash) to propagate non-OK statuses from `UpdateLocked()`. When I first made the dualstack changes, I didn't bother with this plumbing, because there are no cases today where these code-paths will actually see a non-OK status (`EndpointAddresses` won't allow creating an endpoint with 0 addresses, and that's the only case where pick_first will return a non-OK status), and I wasn't sure if we would stick with the approach of returning status from `UpdateLocked()` due to the aforementioned lazy creation case. However, now that we have a good solution for the lazy creation case, I've added the necessary plumbing, just so that we don't have a bug if in the future pick_first winds up returning non-OK status in some other case.
I have not bothered to fix the propagation in the grpclb policy, since that looked like it would be slightly more work than it's really worth at this point.
Closes#36463
COPYBARA_INTEGRATE_REVIEW=https://github.com/grpc/grpc/pull/36463 from markdroth:lb_reresolve_for_lazy_child_creation 49043b2d80
PiperOrigin-RevId: 629755047
76c93769e2