Fix Server.Builder#build() silently overriding an explicit AddressResolver

[roydahan]

Problem

Server.Builder#build() unconditionally replaced the configured AddressResolver with a fresh NodePerPortResolver whenever withMultipleNodesPerIp(true) had been set, regardless of the order in which builder methods were called:

AddressResolver addressResolver = this.addressResolver;
if (multipleNodesPerIp) {
  addressResolver = new NodePerPortResolver();
}

This meant a caller who did:

Server.builder()
    .withMultipleNodesPerIp(true)
    .withAddressResolver(myCustomResolver)
    .build();

would have myCustomResolver silently discarded at build() time and get a NodePerPortResolver instead, even though withAddressResolver(...) was called after withMultipleNodesPerIp(true). There was no way to combine withMultipleNodesPerIp(true) (needed for its peer-metadata behavior via PeerMetadataHandler(multipleNodesPerIp)) with a custom address/port allocation strategy.

Fix

withMultipleNodesPerIp(true) now sets this.addressResolver = new NodePerPortResolver() eagerly, at the time it is called, instead of the resolver being forced in build(). This matches the ordinary "last call wins" semantics of every other Builder setter, and matches upstream datastax/simulacron's behavior in the same method:

public Builder withMultipleNodesPerIp(boolean enabled) {
  this.multipleNodesPerIp = enabled;
  if (enabled) {
    this.addressResolver = AddressResolver.nodePerPortResolver;
  }
  return this;
}

With this change, a withAddressResolver(...) call made after withMultipleNodesPerIp(true) is honored, while a withMultipleNodesPerIp(true) call made after withAddressResolver(...) still overrides it with the default NodePerPortResolver (again matching upstream / normal builder semantics).

Tests

Added two unit tests to ServerTest:

• testMultipleNodesPerIpShouldNotOverrideAddressResolverConfiguredAfterwards - builds a Server with withMultipleNodesPerIp(true) followed by a custom withAddressResolver(...), and asserts the custom resolver is actually used to assign the registered node's address (previously this would have gotten a NodePerPortResolver-assigned address instead).
• testMultipleNodesPerIpShouldOverrideAddressResolverConfiguredBefore - confirms the reverse call order still installs a NodePerPortResolver by default.

Ran the full test suite locally (mvn test across all modules): 195 tests, 0 failures.

Context

Found while diagnosing a flaky Simulacron-backed integration test in scylladb/java-driver: scylladb/java-driver#1017. That PR was closed in favor of fixing the root cause here rather than working around it with retries on the driver side - retrying doesn't reliably help because every retry recreates a Server, whose build() always re-hardcoded NodePerPortResolver starting at the same two ports (49152/49153), which doesn't help against a port held in TIME_WAIT. Once this is released, a follow-up PR against java-driver will bump the Simulacron dependency and configure a collision-safe resolver alongside withMultipleNodesPerIp(true).