break up set-watches on reconnect into multiple packets

[jhump]

This fixes an issue wherein a client that has a very large number of watches (and/or very long path names that are being watched) could cause a disconnect to be effectively permanent: the client gets stuck in a loop of trying to reconnect but being continually disconnected by the server.

This happens because the client may try to construct a request that is too large for the server to process. A ZK server, by default, limits incoming requests to 1mb. The hard-coded request buffer size in this client is 1.5mb.

It also fixes a related possible bug where the connection is successfully re-established, but watches are silently lost (because the set-watches request is so big it results in ErrShortBuffer when trying to encode the set-watches-request packet).

[jhump]

@samuel, this is a serious bug that we are encountering because we have apps that watch a reasonably large sub-tree in ZK and end up needing to re-establish a very large number of watches on reconnect. This changes this Go client to behave just as the Java client does to mitigate this possible problem.

[coveralls]

Coverage increased (+0.3%) to 81.456% when pulling bc3c542 on jhump:jh/break-up-set-watches into 1d7be4e on samuel:master.

[coveralls]

Coverage increased (+0.3%) to 81.456% when pulling ea865e5 on jhump:jh/break-up-set-watches into 1d7be4e on samuel:master.

[samuel]

Thanks again for the contribution. Seems there's a conflict after merging the other PR, but I'll merge this right away once that's resolved.

[coveralls]

Coverage increased (+0.3%) to 81.887% when pulling 991e2f5 on jhump:jh/break-up-set-watches into 789e9fa on samuel:master.

[jhump]

Thanks for the fast merge @samuel!