Comment 2 for bug 237210

Some of the existing MailingListStatus values should indicate that it's safe to do renaming and merging operations. For exmaple, DECLINED pretty much guarantees that there's no mailing list on the MM side. INACTIVE does too, though there will be a tarball artifact. FAILED very likely means there is no list on the MM side (though part of the creation could have failed).

For a list in at least these three states, it should be fine to perform the rename or merge operation. The checks in the code should be changed to both check to see if the MailingList for the team does not exist, or if it's in one of those three states. On a rename in one of these states, it's probably fine to just delete the MailingList row, though there may have to be other tables to update (MessageApproval) comes to mind. For INACTIVE and FAILED, a XMLRPC command probably needs to be issued: PURGE to ensure that no lingering artifacts exists. Does the PURGE need to be acknowledged? (What if it fails?)

Adding the basic infrastructure for this would allow us to possibly also address question 41393 by exposing a different u/i for the LP admin. The LP admin should be able to go to a team with a list in DECLINED state, and remove the MailingList row, thus allowing for it to be reapplied for. We don't want to do this automatically, because presumably if a list has been declined, it was for a good reason and we don't want to allow team admins to just annoy the LP admins with repeated requests.