client: fix race between connection error and subconn shutdown

[dfawley]

This is something I noticed when adding the SubConn.Shutdown method in #6493, but never observed. If we fail to check ac.ctx while holding ac.mu, then the following race is technically possible:

1. In resetTransport, tryAllAddrs is called and returns an error. acCtx (AKA ac.ctx) .Err() == nil as the addrConn is still in use.
2. From the LB policy, RemoveSubConn (or SubConn.Shutdown) is called. This sets the state to Shutdown and cancels ac.ctx.
3. Back in resetTransport, we grab ac.mu and update the state to TransientFailure.

The net result is the LB policy's state listener (or UpdateSubConnState) will receive Shutdown followed by TransientFailure. All LB policies should be ignoring updates after Shutdown anyway, but this is still an incorrect transition.

I don't believe this case is worth trying to stimulate with a test. The race window is extremely tiny, and such bugs could have easily existed in several other places in our code. I confirmed via manual inspection that everything either checks ac.ctx or ac.transport while holding ac.mu before calling ac.updateConnectivityState.

RELEASE NOTES: none