Eternal watch should be robust when blocks are slow

[lazyatom]

In order to ensure that we don't miss any key changes while we are doing work, the eternal_watch method should track the modifiedIndex attribute of the previous response and watch again using the next index value.

This pull request also adds specs for the other basic behaviours of eternal_watch, and fixes a minor but when it is called with only one argument.

[ranjib]

@lazyatom this library is not actively maintained. Let me know if you would be interested in taking over maintainership

[lazyatom]

It would probably be more pragmatic to work with @davissp14 to merge in his v3-compatible codebase here, and then use that as the basis for future development. I'd be happy to help facilitate that (including handing off ownership from you, if you like), if it's something you are both interested in?

[davissp14]

My goal is to actually get these projects under the CoreOS account. I think this will be a better long term solution for both Etcd and for dealing with the inactive maintainer issue.

It would probably be more pragmatic to work with @davissp14 to merge in his v3-compatible codebase here, and then use that as the basis for future development.

I personally don't like the idea of munging the v2 and v3 codebases as they are and should be thought of as completely different databases. I think/hope that the duel support going on in the v3 binaries is a short-term solution to account for the immature v3 client driver ecosystem.

Relevant Issue: https://github.com/coreos/etcd/issues/9156

[lazyatom]

My thinking was to branch this code as v2, add your code as master and start releasing your code as the etcd gem with a major version bump (maybe even up to v3) to indicate the API change. Anyone who needs to stick with the v2 API can continue sticking with the old code (and fixes can go on the v2 branch with releases under the current major gem version).

What I'd most like to see is that the "official" gem (either eventually under CoreOS' account, or semi-official if not) be able to use the etcd name on RubyGems.org, without breaking stuff for existing users (beyond locking up their version dependencies).

If @ranjib is happy to transfer/share gem ownership then we could achieve this without the codebases living in the same repository, but it might be confusing for users reporting issues if the codebases don't live together (albeit separated via git history and branches).