Don't tear down an Observer when we lose connection to the Leader

As things are right now, when an Observer loses connection to the
Leader it tears itself down and goes into LOOKING state. This is
very suboptimal (dropping clients, being unavailable, etc.).

With this change an Observer will do the following when it loses
connection to the leader:

a) it'll close the datatree (i.e.: the txnlog)
b) it'll signal a WatchedEvent to all clients informing a new of a
   new KeeperState (Connected.ReadOnly)
c) any writes will now fail with not-read-only-operation
d) it'll start looking for a leader from the QuorumPeer thread (the
   main thread) without shutting down the ObserverZooKeeperServer instance
   so clients are preserved and can keep reading (they'll have to set
   watches again when we transition back to SyncConnected though)
e) when a leader is found (again) it'll instantiate a new ZKDatabase
   and sync up with the using that
f) once the new ZKDatabase is up to date it'll use that to replace the
   old/current ZkDatabase from ObserverZooKeeperServer
g) it'll signal a WatchedEvent to all clients (new KeeperState is SyncConnected)
h) writes can now happen

Note that this only works for read-only clients; other clients are kicked out
when read-only mode kicks in to retain the original connection state semantics.

Also - this requires a client side change: when transitioning from CONNECTED_RO
to CONNECTED watches need to be reset since the server has a new ZkDB (resetting
the watches is already the case when going from DISCONNECTED to CONNECTED so this
isn't a big change).

Right now this patch only changes the Java client libs - the C libs will be updated
in the next iteration.