Patch to avoid mailboxesdb corruption on concurrent renames

[Bron Gondwana]

I've put a header on the patch describing the bug.  Basically,
the result code from mailbox_open_locked() wasn't being tested
sufficiently, and hence the new mailbox name would be created
in mailboxes.db even though the files were no longer available
to be copied - causing sync bailouts and IOERRORs and all sorts
of fun.

What causes this?  Clients that send a RENAME or DELETE event
and then you do something else in the GUI and they open a
_separate_ connection which tries to do something else to the
source folder.

I think it is our only remaining source of bailouts!  It
requires a reconstruct to fix when it happens.

Patch attached, and the perl script I used to confirm that it
existed and confirm that this patch fixed it.

Regards,

Bron ( P.S. isn't it about time for a 2.3.12?  I'm getting sick
       of posting skiplist patches to people running the
       lastest and having issues! )
-------------- next part --------------
A non-text attachment was scrubbed...
Name: multirename.pl
Type: text/x-perl
Size: 2020 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20080404/885d0e39/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cyrus-renamesafety-2.3.11.diff
Type: text/x-diff
Size: 1760 bytes
Desc: not available
Url : http://lists.andrew.cmu.edu/pipermail/info-cyrus/attachments/20080404/885d0e39/attachment-0001.bin