MINOR: map/acl/dumpstats: remove the "Done." message

By convention, the HAProxy CLI doesn't return message if the opration
is sucessfully done. The MAP and ACL returns the "Done." message, an
its noise the output during big MAP or ACL injection.

(cherry picked from commit 07e78c50b524a25a8fa67f107429fc68d78e14f5)
[wt: this is not a bug but better clean that as it annoys users, so
it's better to backport it to stable]
BUG/MAJOR: stream-int: properly check the memory allocation return

In stream_int_register_handler(), we call si_alloc_appctx(si) but as a
mistake, instead of checking the return value for a NULL, we test <si>.
This bug was discovered under extreme memory contention (memory for only
two buffers with 500 connections waiting) and after 3 million failed
connections. While it was very hard to produce it, the fix is tagged
major because in theory it could happen when haproxy runs with a very
low "-m" setting preventing from allocating just the few bytes needed
for an appctx. But most users will never be able to trigger it. The
fix was confirmed to address the bug.

This fix must be backported to 1.5.
(cherry picked from commit a69fc9f803c05de93b03fc7d4a28d5c503c6d3c9)
BUG/MEDIUM: memory: fix freeing logic in pool_gc2()

There's a long-standing bug in pool_gc2(). It tries to protect the pool
against releasing of too many entries but the formula is wrong as it
compares allocated to minavail instead of (allocated-used) to minavail.
Under memory contention, it ends up releasing more than what is granted
by minavail and causes trouble to the dynamic buffer allocator.

This bug is in fact major by itself, but since minavail has never been
used till now, there is no impact at least in mainline. A backport to
1.5 is desired anyway in case any future backport or out-of-tree patch
relies on this.
(cherry picked from commit 57767b80329ceade67302aed4fd9760ed5f3d644)
BUG/MEDIUM: compression: correctly report zlib_mem

In zlib we track memory usage. The problem is that the way alloc_zlib()
and free_zlib() account for memory is different, resulting in variations
that can lead to negative zlib_mem being reported. The alloc() function
uses the requested size while the free() function uses the pool size. The
difference can happen when pools are shared with other pools of similar
size. The net effect is that zlib_mem can be reported negative with a
slowly decreasing count, and over the long term the limit will not be
enforced anymore.

The fix is simple : let's use the pool size in both cases, which is also
the exact value when it comes to memory usage.

This fix must be backported to 1.5.
(cherry picked from commit 4f31fc2f28f09cb1bcd27af3367ee5acea29b656)