Require ZMQ version 4.x and update/cleanup zmq docs

[jmcorgan]

This PR changes the configure.ac to require ZMQ version 4.x or newer, which is provided on Debian and derivatives as package libzmq3-dev. It also updates the release notes, build-unix.md, and zmq.md docs to reflect this change and add missing documentation.

(Whitespace changes are purely trimming of extraneous previous whitespace by my editor.)

[laanwj]

as discussed on IRC, I'd prefer to not have the unnecessary whitespace changes here in sections you're otherwise not touching

[laanwj]

utACK apart from unnecessary space changes in build system

[gavinandresen]

utACK.

Suggested addition, add zeromq to the build-osx.md dependencies:

diff --git a/doc/build-osx.md b/doc/build-osx.md
index 201fe95..af0d2c4 100644
--- a/doc/build-osx.md
+++ b/doc/build-osx.md
@@ -32,7 +32,7 @@ Instructions: Homebrew

 #### Install dependencies using Homebrew

-        brew install autoconf automake berkeley-db4 libtool boost miniupnpc openssl pkg-config protobuf qt5 libevent
+        brew install autoconf automake berkeley-db4 libtool boost miniupnpc openssl pkg-config protobuf qt5 libevent zeromq

 NOTE: Building with Qt4 is still supported, however, could result in a broken UI. As such, building with Qt5 is recommended.

(installs ZMQ version 4.1.3 right now)

[jmcorgan]

Those changes all remove excess or invisible whitespace, which my editor does as a way of not introducing them in the first place. I'd rather not turn this feature off only when editing bitcoin source code.

[jmcorgan]

@gavinandresen I think there is an existing PR for that, I'll check.

[laanwj]

Those changes all remove excess or invisible whitespace, which my editor does as a way of not introducing them in the first place. I'd rather not turn this feature off only when editing bitcoin source code.

@jmcorgan I understand it's annoying to have to change editor settings per project. But unnecessary whitespace changes create more merge conflicts/rebases. This is acceptable for relatively seldom changing files like the documentation, but not for e.g. configure.ac. Changes to code should be as localized as possible.

[theuni]

tangentially related: I have a fixed version of #6686 coming up, just doing a few tests first.

[theuni]

There are docs illustrating how to remain compatible with the 2.x api here: http://zeromq.org/docs:3-1-upgrade

Since there are obviously lots of 2.x/3.x libs still in the wild, I think it makes sense to try to support them instead.

[jmcorgan]

I'll leave it to the core-devs to decide what compatibility they want to introduce here. If previous API compatibility is desired, there will need to be code changes, and we'll start this process all over again. Alternatively, it could be accepted as-is, and if it turns out users want that, it could be changed at that point.

[theuni]

@jmcorgan What do you mean by starting the process all over again?

I've pushed a change here that fixes build with >=libzmq 2.2.0: theuni@a89a62f

Verified that the rpc tests are successful.

I also went through the rest of the API migration guide and verified that we don't violate any rules for API compatibility, so this really is just a matter of fixing builds.

[jmcorgan]

I mean code review, testing, etc. I've done it for ZMQ 4.x, but not the earlier ones. If the rpc tests are sufficient, then that's great.

[jgarzik]

ut ACK

[ghost]

ut ACK. Interesting that build notes slipped through.

[laanwj]

2.x support is something for a different pull and shouldn't hold up getting the documentation in order.

I'm personally not sure it's worth it - zmq is an optional dependency so people that want to use it can make sure they have the right version installed. Supporting 2.x-4.x extends the spectrum over which testing has to be done (once you promise a version will work, users expect it to keep working), and if we ever decide we want to use more of the zmq API it's a self-imposed pain.

[ghost]

Agreed with the PR split. May want to reconsider the setting, as being enabled by default might be construed as a "promise a version will work."