Support room subjects

[cburschka]

This is one part of the core XEP that still isn't implemented.

group chat messages with an empty body and a non-empty subject signify a room subject.

1. Client sends it to change subject
2. Server reflects it to all occupants
3. Server stores it persistently and sends it after the room history to every new occupant.

This suggests several features in cadence:

1. /subject command attempts to set subject. (The server may deny this, so handle it in a promise that resolves on seeing the reflected message and rejects on error)
2. Room context menus get an option with a popup. Note that restricting subject change to mods is default but not required, so check the room configuration (which we should already be requesting on join and conf changes) to see if it should be grayed out.
3. Store the subject in a room context variable (like history). Set it if the server sends it, and show a message if it changes. As it is part of the persistent history, it should not be redisplayed if the client reconnects.

[cburschka]

It's really annoying that room subjects aren't dated. There is no way to tell subject changes from automatic notifications on joining. This means the "new" string should more ambivalently state "The room subject is {}" rather than "X has changed the room subject.".

[cburschka]

Actually ejabberd does date room subjects. From experiment, I have found the following information:

1. Subject-changes are recorded as messages in the room's history.
2. An undated subject (as specified in XEP-0045) will be sent if and only if:
   1. The most recent subject change is not included in the history, AND
   2. The subject is not empty.

This isn't as flagrantly violating the standard as it used to, but it's still wrong. The XEP explicitly states that the subject change should always be sent AFTER the discussion history, and it should be sent even if the subject is empty.

Cadence should expect conformant behavior but behave unsurprisingly otherwise.

1. For delayed subject messages, print "X has set the subject to Y" (inserted in the room history).
2. For non-delayed subject messages:
   1. If at least one previous non-delayed message exists, go to 3.
   2. If at least one previous subject change message exists, and the most recent one was either non-delayed or had different subject/author, go to 3.
   3. Otherwise, if the subject is non-empty, print "The current subject is Y (set by X)".
3. Print "X has set the subject to Y".

[cburschka]

Explanation:

If the server follows the standard, then it will always send a non-delayed <subject> message on joining, even if it is empty. This should be printed as "The current subject is" to avoid giving the impression that the subject was set just then. If there are subject changes in the room history, then this initial message will be identifiable by being identical to the most recent archived change.

If the server behaves like ejabberd, then it only sends an initial subject if no archived subjects exist. We can only distinguish between the initial subject and an actual subject change by assuming that it must be the first message sent to the room.

The pathological case is if we're using ejabberd, and a user sets the subject shortly before we join, and then sets it to the same value immediately after we join, before anyone else has talked. In this case we will mistake the subject change for an initial subject. That shouldn't happen often.

[cburschka]

Update: just ignore ejabberd's behavior and code for the spec for now.

That means discarding subjects and assuming the first real subject (empty or not) is the initial one sent by the room.