[PATCH] Allow MemPool late initialization

The problem:

> On 24/06/11 02:43, Kinkie wrote:
>> Hi all,
>>
>> 2011/06/23 16:38:39 kid3| assertion failed: mem.cc:516: "MemPools[t]"
>>
>> at startup
>>

FQDN had memDataInit() in its component setup, which moved. The assert
is in memCheckInit() and tests that memInit() worked properly. But if a
pool is initialized only when its component is loaded, that check will
fail on several conditions unrelated to the operation of memory.
Seemingly trivial changes to component loading order is one case.

This patch allows modules to initialize/register their own pools on
demand later in the startup process.

* shuffle MEM_DONTFREE which is an existing fixed entry that must not be
memInitCheck()'d to the end of the MemPool type enum list.

* update memCheckInit() to stop scanning for missing pools at that marker.

* shuffle pool types which are initialized by their components after the
marker value. Such that no false problem is reported if (a) the
component is never initialized for that worker, or (b) the component is
only initialized during the configuration process.

* document this layout significance in the enum list to aid future pool
additions or moves.

* add asserts to memAllocate() and memFree() to highlight the cases of
brokenness memCheckInit() was catching. Using assert() instead of if()
so that optimized builds can avoid the penalty of an extra test on each
alloc/free.

NP: so far this patch gets me past the assert Kinkie hit (and two others
similar). Then dies in Strand.cc (2 workers, minimal config) with a
Segmentation fault that should not exist and cannot be replicated using -N.

Can someone else verify please?

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.12
   Beta testers wanted for 3.2.0.9 and 3.1.12.3