Adapt the APR memory pool for use by Rust code

[khklau]

In Apache2 modules allocating from the heap via any malloc implementation is forbidden. Instead modules are expected to allocate via the supplied APR memory pools.

To allow the std Rust containers to be used the APR memory pool must be adapted to fit one of the allocator traits and it must be set as the default global allocator.

[khklau]

Apparently Apache 2.4 provides access to a memory pool per thread.

[khklau]

After more research the pool is designed as a per request heap.

For allocations within a hook callback or per thread lifetime a non-pool allocator is allowed, albeit it must be the same system allocator used by Apache, which would be the Glibc allocator.

[khklau]

The pattern for Apache modules to store request metadata is: 1) Use the pool in request_rec to allocate space for your metadata structure 2) Save the pointer the metadata structure in the request_config field of request_rec via ap_set_module_config

[khklau]

There are a number of memory pools available for use:

• global pool - stored in the process_rec and is cleared upon process normal exit; designed for per process data
• configuration pool - stored in process_rec and is cleared upon restart (configuration refresh)
• connection pool - stored in conn_rec and is cleared upon connection drop; designed for per client connection data
• request pool - stored in request_rec and is cleared upon request finish

[khklau]

Now that issue#7 is resolved we don't need the memory pools for convenient allocation since nothing is more convenient than the global allocator.

Having values with lifetimes bound to a configuration, connection or request however is still useful.

Some initial idea for how this could be implemented are:

• heap storage is taken from the global allocator, but the Boxes themselves are stored in an array from a pool and drop happens via a function registered using apr_pool_cleanup_register
• create new Box types per pool type which take heap storage from the pool; note that this does not address containers

[khklau]

The plan is to now:

1. use the system allocator as the global allocator so that std containers continue to work like normal
2. create a new PoolBox type that backed by a memory pool, which is instantiated via Box::new_in
3. to tie the lifetime of values allocated on the heap via the global allocator to a particular scope (process, connection, request etc), create a PoolBox context struct that drops via apr_pool_cleanup_register. Then the regular Box and container values are stored in the context.

[khklau]

As an alternative PoolBox might not even be needed. The context structs can be constructed on the heap via the global allocator and the context can be forcefully dropped via the cleanup function that is registered to the pool.