[REQ] Pair can be immutable and HttpBearerAuth more performant; not all generated code is Google code-style

[ronreynolds]

Is your feature request related to a problem? Please describe.

the <invoker>.Pair class has mutable fields only because it has private setter methods (which are only invoked from the ctor). setting those fields directly means they can be final and thus the class immutable (and, thus, thread-safe). as these methods are private this change is backwards-compat.

auth.HttpBearerAuth also has an final field (scheme) which is only set in the ctor but checked for case on every invocation of applyToParams(). as scheme is never exposed we are free to fix its case once on creation. HttpBearerAuth.applyToParams also uses an overly-complex ternary operator in the form of Optional.ofNullable(ref).map(lambda).orElse(null); which ref ? ref.get() : null; is much clearer to read and more performant.

Describe the solution you'd like

#20743

Describe alternatives you've considered

Pair can stay mutable (i.e., not intrinsically thread-safe) and HttpBearerAuth can continue to repeatedly change "bearer" to "Bearer" and create throw-away Optional objects (if tokenAupplier is not null) and invoke get() thru a method-ref and incur totally avoidable performance hits. 😦

Additional context

please see #20743

[ronreynolds]

merged into 7.15.0 🥳