Let mod_client_state handle the queueing of stanzas, not just their
classification. This simplifies the ejabberd_c2s code and gives
(custom) CSI modules more flexibility.
When stanzas are bounced from the stream management queue (because the
session timed out or was closed for some other reason), use a different
error message so that this situation can be distinguished from other
cases.
As per XEP-0016 and XEP-0191, return a service-unavailable error when an
incoming last activity query was blocked by a privacy list (just as we
do for other IQ requests).
If the "resend_on_timeout" option is set to 'if_offline' and a pending
stream management session is terminated because a new session is opened
by the same resource (while no other resource is online), resend
unacknowledged messages rather than bouncing error messages.
If a stream management session times out for a user who appears to be
using MAM, drop any unacknowledged messages rather than resending or
bouncing them. This avoids duplicates or bogus error messages.
However, this is only done if the new mod_mam option "assume_mam_usage"
is set to 'if_enabled' or 'on_request'. In the former case, a user is
assumed to be using MAM if archiving is enabled for his account. In the
latter case, MAM usage is assumed only if archiving was explicitly
requested by the client, or if archiving was enabled by means of
mod_mam's "request_activates_archiving" option.
If a message stanza is blocked as per XEP-0016 or XEP-0191, return an
error only if the type of the blocked message is "normal" or "chat".
This makes sure users won't be kicked from MUC rooms when blocking other
participants.
Closes#897.
The stop/1 function now terminates stream management sessions
immediately, just as it does for other sessions. The new
ejabberd_c2s:close/1 function can be used to close the socket without
terminating the stream management session, like stop/1 did before.
When an XEP-0198 session times out, always return an error for
unacknowledged IQ stanzas, and always drop presence stanzas. That is,
the "resend_on_timeout" option no longer applies to those stanzas types,
but only to messages.
In the past, the "resume_timeout" option defined both the default resume
timeout and the maximum resume timeout clients are permitted to request.
Admins might want to allow clients to request a timeout value that's
larger than the default, though. This can now be done by specifying the
"max_resume_timeout" option.
During login, clients might receive a relatively large number of stanzas
in one go. For some users, the default value of the "max_ack_queue"
option turned out to be too small in that situation.
