BUG/MEDIUM: pattern: don't trim pools under lock in pat_ref_purge_range()

There's a subtle issue that results from pat_ref_purge_range() trying
to release memory. Since commit 0d93a8186 ("MINOR: pools: work around
possibly slow malloc_trim() during gc") that was backported to 2.3,
trim_all_pools() now protects itself against concurrent malloc() and
free() by isolating itself. The problem is that pat_ref_purge_range()
must be called under a lock, which is precisely what's done in
cli_io_handler_clear_map(). Thus during a clearing of a map, if
another thread tries to access or update an entry in the same map, it
will wait for the ref->lock to be released, and trim_all_pools() will
wait for all threads to be harmless, thus causing a deadlock. Note
that disabling memory trimming cannot work around the problem here
because it's tested only under isolation.

The solution here consists in moving the call to trim_all_pools() to
the caller, out of the lock.

This must be backported as far as 2.4.

src/map.c

@@ -1027,6 +1027,8 @@ static int cli_io_handler_clear_map(struct appctx *appctx)
 		applet_have_more_data(appctx);
 		return 0;
 	}
+
+	trim_all_pools();
 	return 1;
 }
 

src/pattern.c

@@ -2090,9 +2090,6 @@ int pat_ref_purge_range(struct pat_ref *ref, uint from, uint to, int budget)
 	list_for_each_entry(expr, &ref->pat, list)
 		HA_RWLOCK_WRUNLOCK(PATEXP_LOCK, &expr->lock);
 
-	if (done)
-		trim_all_pools();
-
 	return done;
 }