Add an option for using dedicated ZkConnection in ZkBaseDataAccessor

[narendly]

Issues

• My PR addresses the following Helix issues and references them in the PR description:

Resolves #654

Description

• Here are some details about my PR, including screenshots of any UI changes:

There are usage patterns where a user needs to create ephemeral nodes using a ZkBaseDataAccessor. We need to support this use case since we want users to avoid using ZkClient directly, so we do it in ZkBaseDataAccessor, which is Helix's wrapper API around the raw ZkClient.

The default behavior would be to use a shared ZK connection resource.

Tests

• The following tests are written for this issue:

Tests for Dedicated and Shared ZkClients already exist in the repository.

• The following is the result of the "mvn test" command on the appropriate module:

[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR] TestCardDealingAdjustmentAlgorithmV2.testAlgorithmConstructor:127 expected:<9> but was:<6>
[ERROR] org.apache.helix.controller.strategy.crushMapping.TestCardDealingAdjustmentAlgorithmV2.testComputeMappingForDifferentReplicas(org.apache.helix.controller.strategy.crushMapping.TestCardDealingAdjustmentAlgorithmV2)
[ERROR] Run 1: TestCardDealingAdjustmentAlgorithmV2.testComputeMappingForDifferentReplicas:273 Total movements: 4 != expected 8, replica: 1
[ERROR] Run 2: TestCardDealingAdjustmentAlgorithmV2.testComputeMappingForDifferentReplicas:273 Total movements: 4 != expected 8, replica: 2
[ERROR] Run 3: TestCardDealingAdjustmentAlgorithmV2.testComputeMappingForDifferentReplicas:273 Total movements: 14 != expected 21, replica: 3
[INFO] Run 4: PASS
[INFO] Run 5: PASS
[INFO]
[ERROR] TestRebalanceRunningTask.testFixedTargetTaskAndEnabledRebalanceAndNodeAdded:298 expected: but was:
[INFO]
[ERROR] Tests run: 883, Failures: 3, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE

---

[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 19.178 s - in org.apache.helix.integration.task.TestRebalanceRunningTask
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 23.770 s
[INFO] Finished at: 2019-12-12T08:56:34-08:00
[INFO] ------------------------------------------------------------------------

[INFO] Tests run: 27, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.469 s - in org.apache.helix.controller.strategy.crushMapping.TestCardDealingAdjustmentAlgorithmV2
[INFO]
[INFO] Results:
[INFO]
[INFO] Tests run: 27, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 5.009 s
[INFO] Finished at: 2019-12-12T08:58:18-08:00
[INFO] ------------------------------------------------------------------------

Commits

• My commits all reference appropriate Apache Helix GitHub issues in their subject lines, and I have squashed multiple commits if they address the same issue. In addition, my commits follow the guidelines from "How to write a good git commit message":
  1. Subject is separated from body by a blank line
  2. Subject is limited to 50 characters (not including Jira issue reference)
  3. Subject does not end with a period
  4. Subject uses the imperative mood ("add", not "adding")
  5. Body wraps at 72 characters
  6. Body explains "what" and "why", not "how"

Code Quality

• My diff has been formatted using helix-style.xml

[jiajunwang]

I revisited the design doc about our ongoing ZK scalability project, it seems that we will migrate this accessor layer to be "zk realm aware". In that case, the raw ZkAddress will mostly be upgraded to a realm address, right? By then, I'm not sure if we still need the type to differentiate or the realm information would be rich enough for us to determine?

[narendly]

This PR is ready to be merged, approved by @jiajunwang

[narendly]

There are usage patterns where a user needs to create ephemeral nodes using a ZkBaseDataAccessor. We need to support this use case since we want users to avoid using ZkClient directly, so we do it in ZkBaseDataAccessor, which is Helix's wrapper API around the raw ZkClient.

The default behavior would be to use a shared ZK connection resource.