don't renew nameplate when CLAIM gets CROWDED

[warner]

In looking at the mailbox server today, I noticed a nameplate in the "crowded" state (three or more sides have attempted to claim it) that has been lingering for over 25 minutes, despite the fact that nobody is currently conencted to it. It looks like the sender disconnected immediately, the first receiver connected later (and submitted a message) but disconnected shortly thereafter, a few minutes later a second receiver connected (getting error=CROWDED) and disconnected, and then more receivers arrived, 3-10 minutes apart, each one getting error=CROWDED.

I'm thinking that an attempt to claim a nameplate which fails should not update the timestamp on the nameplate that keeps it alive. A stream of error=CROWDED should not be able to keep the nameplate alive indefinitely. This ties into #19 where we need CROWDED to be a bit more aggressive in erroring or disconnecting clients.

I'm not sure how to implement this, though. We don't exactly have a "this nameplate is crowded" flag: we represent that by having three or more nameplate_sides rows. And the keepalive/timeout is calculated by looking at the highest timestamp of all those rows. So if we refrain from adding a row (to avoid extending the lifetime) then we're also discarding the information how just how crowded it is.

[warner]

@meejah and I walked through some of this today. We think #20 is the more important bug: well-behaved clients should disconnect when they are given a CROWDED error (or any error), but #20 is probably preventing that. The case that this (#80) would help is when a somewhat-misbehaved client shows up and tries to CLAIM a broken nameplate every 4 minutes, and each CLAIM touches the mailbox and keeps it alive a bit longer. If they didn't show up so quickly, the nameplate would expire, and then their next CLAIM would be a code-in-the-woods case (they'd be creating the mailbox, not opening a pre-existing mailbox), which isn't much better but at least it's not maintaining an obviously-useless mailbox.

The idea would be to change the order of AppNameSpace.open_mailbox and it's internal call to Mailbox.open. Currently open_mailbox creates the mailbox (if necessary), then calls mailbox.open(), then does the crowded check. Internally, mailbox.open() adds the mailbox_sides row (if necessary), and touches the mailboxes timestamp. So the total order of operations is: 1: add mailbox_sides, 2: touch timestamp, 3: check crowded. If we flipped that to 1: add mailbox_sides, 2: check crowded, 3: touch timestamp, then failed OPENs (i.e. OPENs of a crowded mailbox, which gets you an ERROR instead of some MESSAGEs) wouldn't keep the mailbox/nameplate alive any longer than usual.