MESSAGE quota resource implemention

[Rob Mueller]

> Actually, really I'd like to create a new UNIQUEID - and store
> all the files in paths based on uniqueid rather than on folder
> name.  This would not only mean renames could be fast and
> atomic, but that delayed delete would be fast.  The downside is
> a more opaque filesystem layout.  Oh, another upside - file path
> limitations don't exist so much any more.

While UNIQUEID is nice, the opaqueness is annoying. Personally, I liked the 
idea that we talked about a while back which I think was:

$spooldir/a/user/aardvark/user.aardvark/
$spooldir/a/user/aardvark/user.aardvark.drafts/
$spooldir/a/user/aardvark/user.aardvark.trash/
$spooldir/a/user/aardvark/user.aardvark.foo/
$spooldir/a/user/aardvark/user.aardvark.foo.bar/
$spooldir/a/user/aardvark/user.aardvark.abc.xyz/

So you end up with every folder for a user in one dir. This solves the 
current messy handling of sub-dirs (eg currently you have to create the 
intermediate dir /abc/ even though there's no entry in mailboxes.db for it), 
and makes renaming any folder very cheap still (because you can do it with a 
single dir rename, rather than having to move each message file), but you 
don't go completely opaque.

Delete handling is still easier, just rename to DELETED.$oldname.$UNIQUEID 
or something like that, because it's cheap to rename anyway.

Of course it means re-organising folder layout for every installation out 
there, but maybe we need to bump major versions anyway, cyrus 3.0 here we 
come :)

Rob