priority and ring_hash LBs: fix interactions when using ring_hash under priority

[markdroth]

Fixes interactions between the priority and ring_hash LB policies, as per the changes in grpc/proposal#296. Also fixes some unrelated bugs found while looking at the code.

Specific changes in priority:

• Use the same idempotent logic to choose a priority in all cases (e.g., when processing a child connectivity state update and when processing an update from the parent). This avoids problems such as failing to stop using the current priority when it transitions from READY to CONNECTING, but then seeing a duplicate TRANSIENT_FAILURE update from a higher priority that causes us to deselect the current priority because it is in state CONNECTING but does not have a failover timer pending.
• Keep track of whether a child has seen TRANSIENT_FAILURE more recently than IDLE or READY, and use this to decide whether to restart the failover timer when a child reports CONNECTING. This ensures that we properly start the failover timer when the ring_hash child policy transitions from IDLE to CONNECTING at startup.
• Do not cancel failover timer when deactivating a child. This avoids problems where a priority is deactivated while connecting and then reactivated before it finishes connecting.

Specific changes in ring_hash:

• Apply new aggregation rule: If there is at least one subchannel in state TRANSIENT_FAILURE and there are more than one subchannel, report state CONNECTING. If we hit this rule, proactively start a subchannel connection attempt.
• Properly start a proactive subchannel connection attempt at subchannel list creation if the subchannels are already in a state that makes that appropriate. Also update the connectivity state visible to the picker at subchannel list creation.
• Use a ring_hash picker regardless of what connectivity state we report.
• Treat subchannels that go from READY to TRANSIENT_FAILURE as being in state IDLE, as per the gRFC.
• Use logical connectivity state (after applying special cases for sticky-TF and IDLE) for both aggregation rules and for the state visible to the picker.

[apolcyn]

f80fcac looks mostly good

A couple of comments on the test

[markdroth]

Note that I need to merge #29320 before this, so please review that as well. Thanks!

[markdroth]

Looks like the test needs a little more work here. Since merging #29321, the test is no longer failing without the code change here. I'll work on changing it so that it does so.

[markdroth]

I significantly rewrote the test to cover a simpler case but to do it in a way that exerts more control over the timing of the individual subchannel connection attempts. I also simplified the logic in the priority policy so that we always use the same code to choose a priority whenever any child reports a connectivity state change, which should systemically avoid the class of bugs where the logic for choosing a child does not match the logic for reacting to the current child's state changes.

PTAL.

[markdroth]

Eric pointed out that the approach of always starting the failover timer in CONNECTING is not quite right, since that will cause us to select a higher-than-current priority that transitions back to CONNECTING when we have already been using a lower priority that is in state READY. We're still discussing the right way to fix this.