The memory module works as follows. The module remembers ordered lists of
A/V pairs (ordering only guaranteed among attributes of same type) based
on an index value.

On the request list, two attributes are special: 'op' (operation) and 'key'.

The operation given by 'op' can be one of:

	Store		- overwrite data in A/V pair container 'key'
	Add		- add attribute/value pairs to container 'key'
	Concat		- concatenate values with existing attributes
	Load		- retrieve pairs from container 'key
	Load-Purge	- idem, removing pairs from container
	Purge		- remove pair from container

The rest of the attribute/value pairs sent to the module (controlled by
the sendattr acl) are stored and retrieved as-is.

For all operations, an additional last 'int' is returned that contains the
total number of pairs stored in the container before the requested operation
took place.

It is important to note that the module will have a hard maximum amount of
memory available and will remove excess containers on a LRU basis. Therefore
behaviour files must always be prepared for the 'int==0' case and handle this
the same way as an unexpected later packet (eg. reset peer and state machine).

We use the binary module interface for efficiency, and Perl for the efficient
hashes it offers. An external module allows for an easy way to check and
control memory usage and remove state without bringing down the whole server.

If it's a problem from a CPU/memory bandwith/scheduling perspective, we can
always rewrite it in C, and if even that doesn't help enough, optimize this
into an internal module (using a VM trap).