fix: remove duplicate refresh operations

[enocom]

When callers (like the Cloud SQL Proxy) warmup the background refresh
with EngineVersion, the initial refresh operation starts with IAM Authn
disabled. Then when a caller connects with IAM authentication, the
existing refresh is invalidated (because it doesn't include the client's
OAuth2 token). In effect, two refresh operations are completed when the
dialer could have just run one initially.

This commit ensures calls to EngineVersion respect the dialer's global
IAM authentication setting. If IAM authentication is enabled at the
dialer level, then EngineVersion will ensure the refresh operation uses
IAM authentication. And only one refresh operation occurs between warmup
and first connection.

In cases where a dialer is initialized without IAM authentication, but
then a call to dial requests IAM authentication, a second refresh is
unavoidable. This seems to be an uncommon enough use case that it is an
acceptable tradeoff given how IAM authentication is tightly coupled with
the client certificate refresh.

Separately, when Cloud SQL Proxy invocations start the Proxy with the
--token flag in combination with IAM authentication, the underlying
token does not have a corresponding refresh token and so cannot be
refreshed. As a result, when the double calls occur (as described
above), there is a third refresh attempt started because the token has a
missing expiration field (there is only AccessToken, no RefreshToken, or
Expiry).

The dialer sees the missing expiration as an expired client certificate
and immediately starts a new refresh. But because the dialer has already
consumed two attempts, the rate limiter (2 initial attempts, then
30s/attempt) forces the client to wait 30s before connecting.

This commit ensures that situation will not happen by using the correct
client certificate expiration and not the invalid token expiration. For
cases where the Cloud SQL Proxy configures the dialer with the --token
flag (and no refresh token), the dialer will always default to using the
client certificate's expiration. This means the refresh cycle will fail
once the token expires.

Fixes #771

[jackwotherspoon]

why do we need a lock around this?

[enocom]

During my testing, this triggered a race condition between the read here and the write in UpdateRefresh. I wrapped it with a lock to prevent any data races in the case that a refresh is scheduled at the same time a refresh was being updated.

[jackwotherspoon]

LGTM, great PR description 🤩 👏