HDDS-15599. Follow up clean up from HDDS-15531 PR 10486

[kerneltime]

What changes were proposed in this pull request?

Post-merge cleanup addressing @szetszwo's review comments on #10486
(HDDS-15531). He left three minor comments after the merge and asked that
they be handled in a follow-up PR. All three are behavior-preserving.

1. ConnectionFailureUtils — ConnectException and
   NoRouteToHostException both extend SocketException, so their explicit
   instanceof checks were redundant. Removed them (the SocketException
   branch still matches both) and added a comment. They remain listed in the
   class Javadoc as connection-failure shapes.
   (comment)

2. OzoneConfigKeys — moved ozone.client.failover.resolve-needed
   (key, default, and Javadoc) next to ozone.client.failover.max.attempts.
   (comment)

3. OMFailoverProxyProviderBase.maybeRefreshCurrentOmAddress — replaced
   the synchronized null-guard with Objects.requireNonNull for nodeId
   and info. getCurrentProxyOMNodeId() is already synchronized and
   omProxies is an unmodifiable map built once at construction, so neither
   read needs the provider monitor and both values are always present.
   (comment)

No functional changes: the connection-failure classification is identical
(the removed types still match via SocketException), the config constant is
unchanged, and requireNonNull only fast-fails on inputs that cannot occur
rather than silently returning false.

What is the link to the Apache JIRA?

https://issues.apache.org/jira/browse/HDDS-15599

How was this patch tested?

No new tests — these are refactors covered by the existing suites:

• TestConnectionFailureUtils: ConnectException / NoRouteToHostException
  (bare and cause-nested) remain classified as connection failures via the
  SocketException branch.
• TestOMFailoverProxyProviderRefreshWired and TestOMProxyInfoDnsRefresh:
  the refresh wiring is exercised through method overrides, so the internal
  refactor of maybeRefreshCurrentOmAddress does not change their behavior.

mvn checkstyle:check reports 0 violations on both hadoop-hdds/common and
hadoop-ozone/common.

[szetszwo]

+1 the change looks good.

[adoroszlai]

Thanks @kerneltime for the patch, @szetszwo for the review.

[adoroszlai]

@kerneltime please push dev branches (e.g. HDDS-15599-followup-cleanup) to your fork, not apache/ozone