Forbid using canBeReadonly when connecting zookeeper

[depay]

Chronos may get a wrong leader path, which may cause a fatal error that:
once the non-leader instance gets an out-of-date leader path and the wrong
path happens to be itself, it will redirects a request to itself and
then blocks other any requests in less than 1 second. In this circumstance,
scheduler is still running but no rest api responds, even it becomes leader.

So, setting connecting parameter 'canBeReadOnly' to false(default) to provide
Chronos from reading wrong leader info is necessary.

[depay]

#285

[elingg]

Thanks @depay! This change makes sense, and we need to fix this issue so I will merge. Question though, why does the leader path become correct? Shouldn't the HA be properly managed by Curator?

[depay]

@elingg it seems that something wrong with zookeeper at the very moment, chronos gets
the leader-changing event but cannot connect to the zookeeper leader, so it reads a leader path from another zk node. This weak-consistency strategy is supplied by zookeeper directly. Nothing wrong with curator.

canBeReadOnly - (added in 3.4) whether the created client is allowed to go
to read-only mode in case of partitioning. Read-only mode basically means
that if the client can't find any majority servers but there's partitioned server
it could reach, it connects to one in read-only mode, i.e. read requests are
allowed while write requests are not. It continues seeking for majority in the
background. 

[modeyang]

LGTM, thanks @depay, the read-only flag need be false when leader switch.

[elingg]

Thanks for the explanation, @depay. 🚢