draft concept for acl caching

Ok, I've finally had time to sketch out acl result caching.

Here's the top level concept:
If we:
*) Alter the acl checking code to store the result (match, no-match,
unknown, in-progress) of an acl check in a cache.
*) Alter the acl checking code to use the results of an acl check from
cache if possible.
*) define an acl result cache as an associative array (more later on
this).
*) Create optional cache parameters to the acl checklist checks (noth NB
and vanilla). If the cache is not provided, an interim one is created.
*) Add an acl cache to the clientHttpRequest struct and use it in acl
check calls.

we should be able to save significant overhead in complex acl checking
scenarios, for all acl types. Most configs I've seen test the same acl
multiple times in a single request, which is why I think this is useful.

Design sketch:
We assign a unique numeric id to each acl as it is created (say from
global pool), we can cache the results via a simple dynamic vector of
the result types. On reconfigure we only reuse known free acl id's
(which implies refcounting the id values, or some similar scheme).

If anyone is interested, I'd be happy to code up a stats gathering
patch, to roughly estimate the impact a caching scheme could have,
without actually implementing one (and therefor having to get it right
:]).

Rob

-- 
GPG key available at: <http://users.bigpond.net.au/robertc/keys.txt>.