Solution: partially list changes since 4.2.5. Not yet complete.

Solution: bump back from 4.3.1 to 4.3.0

Problem: new radix tree implementation is experimental

Solution: use it only for DRAFT builds for now, to leave it time to be
tested and stabilised.

Problem: potentially large memory footprint of trie as number of subscriptions increases (issue #1400)

Solution: add it

subscriptions increases

Solution: use a radix tree instead of a trie to store subscriptions

Problem: Use of pipe_t after free in zmq::socket_base_t::term_endpoint(). Issue #3245.

Solution: When pipe_t is freed (terminated) remove it from _endpoints member of zmq::socket_base_t. Resolves issue #3245.

Add support for UDP multicast ttl (ZMQ_MULTICAST_HOPS)

Solution: add relicense agreement

Solution: add support for ZMQ_MULTICAST_HOPS (IP_MULTICAST_TTL)

Relicense statement for Hpsaturn

fix for android building

Relicense statement for Juraj Oršulić

Always include ZMQSourceRunChecks.cmake

Solution: fix issue introduced by #3270

Problem: gabm didn't signalise his consent to relicense libzmq

* ZMQ_DGRAM: flip more flag after successful send

In the dgram socket we have a flag that indicates the next expected message type to ensure that always a pair of "address" + "body" messages gets sent. The first one MUST have the sendmore flag, the second MUST NOT.

In case the message does not get sent because of HWM full, then the function returns EAGAIN as it should. But unfortunately the next expected message type-flag gets flipped as well. When the socket_base::send function now tries to resend the message, it became the wrong message type... If you don't stop sending pairs of messages here (like me) then the next message that gets through will be of the wrong type, which in turn crashes the udp_engine function as described in #3268

Problem: Compilation with strict AARCH64 compilers is broken

This patch fixes an issue that occurs on 64-bit architetures under
strict compiler rules. The code initially checked that the received
size stored in 'uint64_t' was not bigger than the max value of a
'size_t' variable, which is legitimate on 32-bit architectures where
'size_t' variables are stored on 32 bits. On 64-bit architectures,
this test no longer makes sense since 'uint64_t' and 'size_t' types
have the same size. The issue is fixed by ignoring this portion
of code when built for arm64.

[ISSUE 2488] Updates the zmq_msg_send doc

Solution: Add more information to the doc specifying that MAX_INT is the maximum
possible return value.

Problem: test_connect_delay_tipc randomly fails

Solution: use a monitor to wait for a disconnect instead of a sleep,
and retry to send a message until it fails since the state machine
might be delayed due to the I/O thread being pre-empted on busy
systems.
Also set a receive timeout to avoid random hangs.

Fixes #3124

Problem: have to ask manually for relicensing grant

Solution: add note in PR template

Problem: INSTALL refers to deprecated VS build instructions

Solution: remove the reference

Remove race condition from XPUB/SUB test in test_blocking()

Fix for test_hwm_pubsub