OF-2157: Ensure proper order of logged messages in cluster
It is important to assign a message ID, which is used for ordering messages in a conversation, soon
after the message arrived, as opposed to just before the message gets written to the database. In the latter
scenario, the message ID values might no longer reflect the order of the messages in a conversation, as
database writes are batched up together for performance reasons. Using these batches won't affect the
database-insertion order (as compared to the order of messages in the conversation) on a single Openfire
server, but when running in a cluster, these batches do have a good chance to mess up the order of things.
OF-2159: Do not re-use origin-id when generating a stanza
This fixes a misunderstanding of the text in the XEP. Although origin-id must be retained, its value shouldn't be re-used, as the local entity can't trust the owner to have used a unique value.
OF-2157: Sequence-manager should be cluster-aware
Openfire has a 'sequence manager' that basically allows you to have unique numbers. We use this instead of a database autoincrement-like mechanism (which is different on every database, and thus hard to use generically in Openfire).
As far as I know, the sequence manager works pretty well in a clustered setup, with one caveat: as the sequence manager obtains a 'block' of sequences to be used, different members might all obtain a block of their own. Although they'd still use distinct values from their blocks, there is no predicting the order in which the values are used. This results in the values added to the database to not be sequential.
This is a problem for things like message logs, which assumes that each message in a conversation is ordered by ID.
This commit ensures that sequence values are stored in a distributed cache, ensuring that all cluster members see the same values, and obtain 'next' sequences under lock.
A drawback here is that there's database interaction (to obtain a new block of sequence values) while there's a cluster-wide lock). That will be limited to the specific sequence though.
Arguably, not all code that uses sequence manager values require the values used to be actually sequential (having them unique might be good enough for some applications). There might be room for optimization here, although it feels safest for now to ensure that all applications do get sequential values, as suggested by the API of the implementation.
As all database interaction is performed under a sequence-specific lock, there should not be a need to 'retry' (in case another process already modified the value). I've removed the retry logic that existed since 2004.
