Merge pull request #213 from twhittock/master

Windows strdup replacement did not correctly initialise memory
Ignoring eclipse setting
Merge pull request #215 from mvala/master

Ignoring eclipse setting
Problem: zyre_set_name() method is extra work

Every new node should set a user-meaningful name so that logging works. The
right place for this is in the constructor.

Solution: remove this method and add the name argument to zyre_new ().
Fixed man pages, were out of date
Merge pull request #218 from hintjens/master

Updated man pages
Fix. Set correct peer status on HELLO

Suppouse we get HELLO with group `CHAT` and status `1`.
If we set peer status and then call `zyre_node_join_peer_group` then
peer status become to `2`.
So we should set status after we call `zyre_node_join_peer_group`.
Fix. Set correct peer status on HELLO

Suppose we get HELLO with group `CHAT` and status `1`.
If we set peer status and then call `zyre_node_join_peer_group` then
peer status become to `2`.
So we should set status after we call `zyre_node_join_peer_group`.
Merge pull request #219 from moteus/master

Fix. Set correct peer status on HELLO
Started implementation of gossip discovery

Selftest is in zyre_node_test

Body of test is still empty, we do gossip setup but don't yet handle
DELIVER messages from gossip network. This commit is meant to show
the Zyre API for gossip discovery.
Connect properly to peers via gossip protocol

Now handles discovery via gossip network as an alternative to beaconing.
The zyre_test method shows an example of this.

This means we can now run Zyre clusters over inproc or IPC rather than
only TCP.
Merge pull request #220 from hintjens/master

Gossip-based discovery now works
Further work on Zyre gossip discovery

Added tools/ztester_gossip, which stress tests this structure.
Right now it's failing due to rapid socket disconnect/reconnect
with "lost messages" errors and an assertion in libzmq/src/fq.cpp.
Merge pull request #221 from hintjens/master

Further work on Zyre gossip discovery
Problem: randomly claiming "lost messages" after reconnects

The sequence detection logic was not correct, and when receiving a
HELLO from a disconnected/reconnected peer, would complain that it
did not expect the sequence number (1).

Solution: clarify in RFC 36 that HELLO always has sequence = 1.

Then, when receiving a message, if it's HELLO, reset expected
sequence to 1.

Lastly, when getting a bad sequence, delete the peer.
Updated man pages
Cleaned-up endpoint announcement

In gossip model, caller specifies bind/connect endpoints explicitly
both for the ZRE protocol and for the zgossip protocol. The API now
tries to explain these better, and provide a method to set the
announced endpoint for ZRE, when it's not the same as the bind
value. Note that zbeacon does all this behind the scenes...
Updated man pages
Fixed Windows build errors (strndup not portable)

Fixes #223
Merge pull request #224 from hintjens/master

Fixes for Windows and HELLO sequencing