These were exposed to users, but have subsequently been removed as
sockopts. They are currently only being used by ZAP, so I've moved it to
a simpl function call (actually it's only used in one case even in that,
so there may be a further simplification possible there).

ZMQ_CONFLATE option is passed to pipepair() which creates a usual
ypipe_t or ypipe_conflate_t and plugs it into pipe_t under a common
abstract base.

- designed for TCP clients and servers
- added HTTP client / server example in tests/test_stream.cpp
- same as ZMQ_ROUTER + ZMQ_ROUTER_RAW + ZMQ_ROUTER_MANDATORY
- includes b893ce set ZMQ_IDENTITY on outgoing connect
- deprecates ZMQ_ROUTER_RAW

Copyrights had become ads for Sustrik's corporate sponsors, going against the original
agreement to share copyrights with the community (that agreement was: one line stating
iMatix copyright + one reference to AUTHORS file). The proliferation of corporate ads
is also unfair to the many individual authors. I've removed ALL corporate title from
the source files so the copyright statements can now be centralized in AUTHORS and
source files can be properly updated on an annual basis.

Zeromq shall never send/receive socket identifiers for sockets in raw
mode. The existing implementation breaks this requirement after
reconnection.

- add unlikely hints
- drop unnecessary assertion
- style fixes

There is no need to require the 'more' flag in the provided message
structure be 0 when pulling message from the session.

    - Created a new option ZMQ_ROUTER_RAW_SOCK
    - Added new raw_encoder and raw_decoder to receive and send messages in raw form to remote client
    - Added test case file tests/test_raw_sock.cpp

    o To create a raw router sock set the ZMQ_ROUTER_RAW_SOCK option
    o ZMQ_MSGMORE flag is ignored for non-id messages
    o To terminate a remote connection send id message followed by zero length data message

Ref: https://zeromq.jira.com/browse/LIBZMQ-417

Significantly reworked the monitoring infrastructure with a more granular per socket API and to play well with monitoring endpoints in application threads

This patch introduces i_msg_sink and i_msg_source interfaces. This
allows us to make message encoder and decoder more general.

Compiling without warnings is a good goal, because it makes
new warnings (which probably indicate bugs) stand out rather
than getting lost in the spam.

My fixes fall into two categories:

    - Adding (void) casts of unused parameters, where their
      unusedness seems like a TODO (or in some cases a bug?).

    - Removing parameter names altogether, where the function
      is clearly a stub that will never use its parameters.

Should be no change in behavior.

There are three versions of monitor_event(), all taking
variadic arguments. The original code just has the first one
creating a va_list and passing that va_list variadically to
the second one... which creates a new va_list and passes it
variadically to the third one... and of course everything
blows up when we try to pull a non-va_list argument off the
stack.

The correct approach matches the C standard library's use
of printf/vprintf, scanf/vscanf, and so on. Once you make
a va_list, you must pass it only to functions which expect
a va_list parameter.

Fixes #415.

Rename the pipeset to terminating_pipes, as suggested by Martin H. Adds
asserts to test the pipe is contained in the terminating set where
appropriate.

This patch, salvaged from a trainwreck accidental merge earlier, adds a
new sockopt, ZMQ_DELAY_ATTACH_ON_CONNECT which prevents a end point
being available to push messages to until it has fully connected, making
connect work more like bind. This also applies to reconnecting sockets,
which may cause message loss of in-queue messages, so it is sensible to
use this in conjunction with a low HWM and potentially an alternative
acknowledgement path.

Notes on most of the individual commits can be found the repository log.

Revert "After speaking with Ben Gray and the discussion on the mailing list, this is an attempt to create a sockopt to allow connecting pipes to not immediately be available for traffic. The problem is in a PUSH to many PULL situation, where there is a connect to a PULL which is not there. This connect will immediately create a pipe (unlike bind), and traffic will be load balanced to that pipe. This means if there is a persistently unavailable end point then the traffic will queue until HWM is hit, and older messages will be lost."

This reverts commit fe3fb419.

Revert "Remove extra brackets as suggested by Martin H, and fix up a comment which was missing a word"

This reverts commit b79aaaf4.

This reverts commit 297af954.

Revert "Remove the extra outpipe handling as the session is quite capable of delaying the creation of the pipe until the connection has happened. Simply don't build the pipe, and let it do that automatically."

This reverts commit 06485d92.

Revert "Fix a number of whitespace issues in various parts of the code, add validation to most calls on the test and take a first stab at implementing the reconnection pipe blocking."

This reverts commit 6f6466f0.

Revert "On the advice of Martin Hurton, removed the new command type and just terminated the pipe in a reconnect situation, and notified the socket of the same. This handles the blocking properly, but at the cost of potentially losing in flight messages. However, this is a reasonable trade off given how much simpler it makes the patch."

This reverts commit c13f1d52.

This reverts commit 55cbdfcf.

Revert "Removing unnecessary outpipe values that had been used for reconnecting existing pipes - no longer needed when using a pipe term for the delay_attach situation."

This reverts commit ace7c99b.

This reverts commit 09956dee.

Revert "When detaching a pipe, as well as checking the delay on connect sockopt is set, also ensure that the protocol is not pgm or epgm as we are not implementing the functionality for multicase types"

This reverts commit 5008f385.

Revert "The previous code to block the socket from receiving on that pipe during a disconnect was vulnerable to a race condition. This code calls with the terminate functions of both ends of the pipe - I believe this should be safer. This required storing a pointer to the socket end of the pipe"

This reverts commit 336f7272.

Revert "Reverted to a simpler shutdown. This seems to disconnect and reconnect the pipe properly, but there is a problem in overall shutdown when the pipe has blocked and reconnected - the session seems to get terminated() called on it only in shutdown for the original pipe, by which point it has been replaced. I am not sure at the moment why this only happens then, but this does mean this patch is broken at the moment"

This reverts commit b84b0079.

Revert "Use the hiccup mechanism to notify the socket end of the pair of the change in state, and have it shutdown that end, and shutdown the local end normally. This seems to resolve the shutdown and race condition issues."

This reverts commit 67497a26.

Revert "As Martin pointed out, there is a race condition in the old code where a pipe could start shutting down after disconnection, but the new one could connect first. This connection would not get a pipe created for it, so the messages could never flow. The simplest way round this would be a flag, but it is possibly for a very bouncy but fast connection to go up and down twice I imagine, so instead I have added a counter. This starts at zero, and will null out the pipe if terminate is called while it is zero. On a disconnect situation the counter is incremented, and the pipe is the not nulled if the value is non zero. In the terminated function it is decremented for each pipe that is shut down, and the assertion that the terminated pipe == the current pipe is skipped while it is non-zero. This should deal with the race condition and not allow any extra terminated() calls without hitting the assertion."

This reverts commit a5f7300d.