fix: Invalidate the SA's AccessToken when createScoped() is called

[lqiu96]

See b/353616562 for more information. This seems to be a very similar issue to #1387.

Invalidating the Access Token via setAccessToken(null) from createScoped(...) should not break any existing workflows. Copying the existing Access Token while modifying the interval fields that make up the Credentials is a regression in behavior that was introduced in v1.14.0 of the Auth-Library.

Example flow for the current state (pseudocode):

Credentials credentials = GoogleCredentials.getADC();
Storage.create(..., credentials) // Access Token is retrieved with the scopes from ADC
System.out.println(credentials.getAccessToken()) // This is a valid access token with the ADC's scopes

credentials = credentials.createScoped("{NEW SCOPES}");
Storage.update(..., credentials) // Access Token is cached and re-used, but the scopes are different
System.out.println(credentials.getAccessToken()) // This is an invalid access token as it still has the ADC's scopes

Without this change, users would be recieving a 403 Access Denied error message. This change to invalidate the access token would force the auth library to retrieve a new valid access token.

Example flow for the new state (pseudocode):

Credentials credentials = GoogleCredentials.getADC();
Storage.create(..., credentials) // Access Token is retrieved with the scopes from ADC
System.out.println(credentials.getAccessToken()) // This is a valid access token with the ADC's scopes

credentials = credentials.createScoped("{NEW SCOPES}");
Storage.update(..., credentials) // Access Token is retrieved with the new scopes
System.out.println(credentials.getAccessToken()) // This is an valid access token as it has the new scopes

[zhumin8]

LGTM.
Just a small comment with the test.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud