anyway we can make this more deterministic? we should avoid random wait.

Changelog needs to be updated for all these changes here - we can do it in a separate PR but mentioning here for reference.

nit, `custom` instead of customer

This looks right to me. @wenjiaswe Would you double check this function as well? Docs for ClientHandshake here: https://godoc.org/google.golang.org/grpc/credentials#TransportCredentials

pointer needed? just do `authTokenMu sync.RWMutex` to eliminate `authTokenMu: new(sync.RWMutex)` below?

``` return &transportCredential{ gtc: tc.gtc.Clone() } ``` ? (I realize we're not using it for anything, but just to future proof..)

Remove comments about picker configuration and `Custom` picker enum in this PR and instead open an issue about it? It's a adds quite a bit of noise in this PR, might be better to just leave it out of the code until we decide to implement something. Same for custom balancers.

balances

nit: Log a warn or something if none of the cases match?

nit: Can we just do: ```go rc.mu.RLock() defer rc.mu.RUnlock() return rc.cur ``` ?

Update comment to reflect that we're calling `updatedPicker` now instead `regeneratePicker`?

do we need to check authority is an IP address rather than a DNS name?

nit: "grpccredentials.TransportCredentials"