fix(oauth2_http): Avoid retrying on 4xx errors during GCE metadata ping

[macastelaz]

Don't retry GCE Metadata 4xx errors which are generally non-retriable errors and only adds startup noise/latency by retrying 3 times.

Fixes #13649

[gemini-code-assist]

Code Review

This pull request updates ComputeEngineCredentials to handle 403 Forbidden responses during the Compute Engine metadata server ping check by immediately returning false instead of logging an unexpected exception. It also introduces a new test case to verify this behavior and adds request counting to MockMetadataServerTransport to ensure no retries occur. There are no review comments, and I have no additional feedback to provide.

[lqiu96]

nit: this can also be done in a follow-up refactor PR if we agree on this.

Do you think we can use HttpRequest's setUnsuccessfulResponseHandler as well as the ExponentialBackoff + setNumberOfRetries to configure retries/ handle failure? Or do you know if there a reason ComputeEngineCredentials can't use that?

google-cloud-java/google-auth-library-java/oauth2_http/java/com/google/auth/oauth2/ServiceAccountCredentials.java

Lines 560 to 566 in faf8530

	request.setUnsuccessfulResponseHandler(
	new HttpBackOffUnsuccessfulResponseHandler(backoff)
	.setBackOffRequired(
	response -> {
	int code = response.getStatusCode();
	return OAuth2Utils.TOKEN_ENDPOINT_RETRYABLE_STATUS_CODES.contains(code);
	}));

[macastelaz]

To be honest, I wouldn't call myself an expert here but here's what Gemini had to say:

"Since pingComputeEngineMetadata is a lightweight detection mechanism that executes on startup for non-GCE environments to check if it's on GCE, we use a strict 500ms connection timeout and try to fail fast. If we were to use ExponentialBackOff , any timeout or retryable network failure would introduce sleep delays between retries, which would exponentially delay application startup on local environments. The manual loop ensures we do 3 rapid checks and fail out without hanging the thread."

Given the small number of retries, I would suspect any additional latency from retry delays would be minimal but in theory, the ideal of wanting to of avoid introducing any additional startup latency to backoff retries makes sense to me. Thoughts?