Do not create a property source if CuratorFramework is null in ZookeeperConfigDataLoader.
Do not register CuratorFramework twice in CuratorFactory
Fixes gh-290
Creates a ZookeeperBootstrapper for users to customize Zookeeper.
Moves CuratorFramework create to CuratorFactory that is used in auto configuration and ConfigData
We currently don't have a simple mechanism to configure CuratorFramework's session and connection timeout.
Since Curator 3.x users can affect how Curator handles re-connection, since the meaning of LOST was changed.
In 3.x when the "Disconnected" is received Curator starts an internal timer.
When the timer passes the negotiated session timeout Curator calls `getTestable().injectSessionExpiration()`
and posts a LOST state change.
In Curator 4.x the session timeout defaults to 60 seconds and the connection timeout to 15 seconds.
Ref:
```
private static final int DEFAULT_SESSION_TIMEOUT_MS = Integer.getInteger("curator-default-session-timeout", 60 * 1000);
private static final int DEFAULT_CONNECTION_TIMEOUT_MS = Integer.getInteger("curator-default-connection-timeout", 15 * 1000);
```
Proposed Solution
=================
Offer a mechanism to configure the session and connection timeout and
establish a mechanism to be able to customize the `CuratorFramework` for
future-proving.
We could avoid having two more properties, the session and connection timeouts, as part of `ZookeeperProperties` and
let users define them on their `CuratorFrameworkCustomizer`. The current rational is that consolidating this two
configuration properties as part of the `spring.cloud.zookeeper` configuration namespace is valuable and simplifies
their usage.
Additional Context
==================
> Curator will set the LOST state when it believes that the ZooKeeper session has expired.
> ZooKeeper connections have a session. When the session expires, clients must take appropriate action.
> In Curator, this is complicated by the fact that Curator internally manages the ZooKeeper connection.
> Curator will set the LOST state when any of the following occurs:
> a) ZooKeeper returns a Watcher.Event.KeeperState.Expired or KeeperException.Code.SESSIONEXPIRED;
> b) Curator closes the internally managed ZooKeeper instance;
> c) The session timeout elapses during a network partition. It is possible to get a RECONNECTED state after
> this but you should still consider any locks, etc. as dirty/unstable.
Ref. [Curator Errors](https://curator.apache.org/errors.html)
Warning: Curator 4.0.1 is affected by [CURATOR-460: Timed tolerance for connection suspended leads to simultaneous leaders](https://issues.apache.org/jira/browse/CURATOR-460). This was addressed in `4.1.0`.
Additional references:
=====================
* [TN14: ZooKeeper's Session Handling](https://cwiki.apache.org/confluence/display/CURATOR/TN14)
* [CURATOR-460](https://issues.apache.org/jira/browse/CURATOR-460)
* [Curator Errors](https://curator.apache.org/errors.html)
fixes gh-244
This commits adds the option to define a Curator `TracerDriver`, which
if available, will be used in the CuratorZookeeperClient wrapped inside the
CuratorFramework.
Fixes gh-241
Fixes gh-242
There was a bug in the evaluation order for ZookeeperHealthIndicator bean where its conditions for creation,
particularly whether there was a CuratorFramework bean, were evaluated too early causing it to always fail.
This commit moves the inner ZookeeperAutoConfiguration.ZookeeperHealthConfig class into its own public class
ZookeeperHealthAutoConfiguration and makes sure its configured as auto configuration after ZookeeperAutoConfiguration.
This seems to resolve the order problem in testing.
Unit tests added for conditions on ZookeeperHealthIndicator bean.
Minor change to ZookeeperHealthIndicator to only call curator getState method once rather than twice.
