Close signups and prevent auto-opening upon user cancellation of signup

This is all logic from signup itself. The idea is for the case where you have a signup limit, and someone cancels -- there's code to check if that canceled signup now means the limit is no longer reached and signups should re-open. There's code that runs at this time to see if the event already started, and if cron would have already auto-closed the event, so we don't re-open "old" events just because someone cancels.

However, I can definitely see the problem you describe, where an admin manually closes signups on an event in the future that has no signup limit, and doesn't want them to reopen just because someone cancels. I'm not sure I'd call the current behavior a bug, but I'll agree it doesn't handle this particular case correctly. ;)

Anyway, this is definitely something that should be fixed in signup itself, not in signup_status, since a) signup_status isn't responsible for this behavior in the first place, and b) I can clear see cases where people not running signup_status would want this new behavior.

All that said, I'm not positive how we should fix this. I see a few options:

A) Is it enough to say that if signups are closed but the limit isn't currently reached, then a canceled signup shouldn't reopen? Seems like that'd cover most of the cases, but there might be edge cases where it still reopens when someone doesn't want that.

If we don't use that heuristic, I can see 2 other possible solutions, neither of which I'm thrilled about:

B) Convert the {signup}.status field from an open vs. closed bool into a multi-valued int (open, closed-time, closed-limit, closed-admin, ...). This is going to require a big patch to touch a lot of places in signup.module -- everywhere we inspect $node->signup_status or query {signup}.status directly, etc. Yikes.

C) Add a new {signup}.close_reason field (or something) to act as the memory of why signups are closed on a given node. This seems less elegant from a code/schema perspective in some ways, but avoids a lot of the pain of approach (B).

Thoughts? Any better suggestions? ;)

Thanks,
-Derek