Summary

Adds a fluent ZkMultiWriteBuilder API for issuing atomic ZooKeeper multi() transactions over Helix property-store paths, exposed via PinotHelixResourceManager.multiWriteZK(). This lets callers mutate multiple property-store znodes (e.g. several SegmentZKMetadata entries ) as a single all-or-nothing batch instead of issuing per-path writes that can leave the property store in a half-applied state on a crash or version-mismatch retry.

helixResourceManager.multiWriteZK()
    .set(segmentPath1, seg1.toZNRecord(), expectedVersion1)
    .set(segmentPath2, seg2.toZNRecord(), expectedVersion2)
    .check(guardPath, guardVersion)
    .execute();   // throws KeeperException on atomic rollback

What's in the API

• set(path, record[, expectedVersion]) — overwrite a znode with optional CAS.
• create(path, record) — create a persistent znode.
• delete(path[, expectedVersion]) — delete with optional CAS.
• check(path, expectedVersion) — version assertion that gates the rest of the batch.
• execute() — submits all accumulated ops as a single ZK multi().

Op paths are property-store-relative (the same paths callers pass to ZkHelixPropertyStore). The builder prepends /{cluster}/PROPERTYSTORE before submitting. Multi-path writes outside the property store are intentionally unsupported.

Error model

On atomic rollback, execute() throws the underlying KeeperException subtype so callers can branch cleanly:

• BadVersionException / NoNodeException / NodeExistsException → retryable concurrent-state changes.
• Other subtypes → hard errors.

Per-op offender info is reachable via KeeperException#getResults(). Connectivity / session failures (timeout, interrupt, session expiry) propagate as the original ZkException since they are not atomic outcomes. The builder is single-use and not thread-safe — obtain a fresh one per transaction.

Why a dedicated ZkClient

Helix 1.3.2 does not expose multi() on BaseDataAccessor, and the ZkClient inside ZKHelixManager is not publicly reachable. Reusing it would require reflection, which breaks across Helix point-releases. PinotHelixResourceManager lazily builds one dedicated ZkClient on first multiWriteZK() call (derived from the started Helix manager's ZK address) and closes it asynchronously on stop(). This is consistent with the controller's existing footprint — _propertyStore and _leadControllerManager already hold their own ZK sessions.

Test plan

• Added ZkMultiWriteBuilderTest covering ops, fluent chaining, single-use guard, path-prefix validation, and KeeperException unwrapping from ZkException.
• Added PinotHelixResourceManagerStatelessTest#testMultiWriteZkSegmentMetadataUpdates — pre-creates two SegmentZKMetadata znodes, updates both atomically via multiWriteZK(), and verifies round-trip read through the property store.
• mvn spotless:apply && mvn checkstyle:check