Test services should retry on BindException after picking a free port

Found while reviewing #19892 (part of #19524).

`HiveTestService` (HiveServer2 port, and the metastore port it already picked this way), and `ZookeeperTestService` choose a port with `NetworkTestUtils.nextFreePort()`, which binds port 0, reads the number and closes the socket. The port is then bound later, and re-bound by every subsequent test class in the same JVM, with no retry. Ports from bind(0) come from the ephemeral range, so another process, Spark or Netty outbound connections, or a sibling surefire fork can take it in between, and every Hive or ZK test in that JVM then fails.

`HdfsTestService` already handles this: #2070 added a five-attempt retry around port selection for exactly this reason.

Proposed fix: retry the pick-and-bind in `HiveTestService.start()` and `ZookeeperTestService.start()` on `BindException`, and expose the JDBC URL and connect string as methods rather than constants so a retried port is visible to callers.

Start at HiveTestService.start() and ZookeeperTestService.start(), then compare their port handling with the five-attempt retry in HdfsTestService. Trace NetworkTestUtils.nextFreePort() and the existing Hive and Zookeeper connection values. Done means BindException during port binding is retried and callers receive the selected port through methods rather than fixed constants.

Written by the indexing model from the issue text.