fix(spring): fix client and settings class names in comments

[emmileaf]

This PR addresses the javadoc error observed in our attempt to set up spring-cloud-previews for release.

Cause of javadoc error: few exceptions of incorrect client library <service>Client and <service>Settings class names

• Misalignment: service.name() vs. service.overridenName() can be different
• This did not raise compilation issues in the generated code, because we used gapic-generator-java’s ClassNames.getServiceClientClassName(service), which correctly aligns with the client library class name.
• service.name() + “Client” was used in other places such as javadoc comments and spring-specific methods and classnames. Turns out this assumption does not hold true.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

100.0% Coverage
0.0% Duplication

[diegomarquezp]

Thanks for ensuring consistency through ClassNames.
A test that compiles comments for one of the failed classes (e.g. AccessApproval[Admin]Client) and confirms the javadoc links are valid would be a nice to have.

[emmileaf]

A test that compiles comments for one of the failed classes (e.g. AccessApproval[Admin]Client) and confirms the javadoc links are valid would be a nice to have.

@diegomarquezp Agreed - I'll merge this PR for unblocking, and follow-up on this suggestion. Were you thinking of some sort of coverage on the generator side (through golden files), or having an earlier check for javadoc links in the spring-cloud-gcp generated code ?