Ghost sessions

Observation: Many of copies of the same stanza like <message type="groupchat" from="#room_example@matrix.org" to="me@example.org/RANDOM_VARYING">

Theory: When disconnecting, sometimes the <presence type="unavailable"/> does not make it to the bridge. If the server policy is to generate a random resource (the JID resource part is a session identifier, not a device identifier!) then these eventually add up in MUCs and the like if not removed.

Background: In XMPP / MUC, clients that silently go offline without the MUC being told end up as "ghosts", appearing to be still present but aren't. These are normally removed when an attempt to deliver a groupchat message to them results in an error returned to the MUC. These kinds of problems were common in XMPP long ago, but were mostly fixed.

Solution: Watch for <message type="error"> in response to groupchat messages, check whether the error condition points to non-deliverability (e.g. one of these) and then remove the user.

Might be a duplicate of #53

Start by tracing the bridge's XMPP/MUC groupchat delivery and error handling; the issue names no repository files or tests. Compare non-deliverability conditions with the linked Prosody MUC conditions and check the possible duplicate, #53. Done means non-deliverable groupchat recipients are removed without treating other message errors as evidence of a ghost session.