Remove restriction for one thread per user/group of users

Problem/Motivation

Apologies if this is a duplicate. I know this has been discussed in the past, but I didn't think there was actually an issue for it and I could find little about it, except this mention by @artem_sylchuk in #3217509-2: Returned thread may exclude some users.

The module currently tries to maintain a single thread for the communication between users and user groups; when sending a particular user or set of users a message, it will search for a thread with just these users (this has actually been buggy in the past, coming up with the wrong thread). This is akin to a model employed by e.g. Apple Messages, where you maintain conversations with users and groups of users. There is, however, one big problem with this. Also, it differs from many other private message models employed by other software

Problem

There is one important difference with Drupal, though; the Private Message module does not own the user data model, and thus can not prevent users to be deleted completely. This may result in "duplicate" threads in this model. For example, consider thread X, between users A and B, and thread Y, between users A, B and C. These are unique threads from the module's point of view. However, when user C is removed from the site completely, both threads X and Y are now between users A and B; it is now no longer clear cut to which thread a new message from user A to user B should be added.

Competing model without the problem

Many software packages offering private message functionality employ a model that is more akin to email, where a message is given a subject and sent to one or more people. The recipients may reply in that thread, or send a completely new message, with a different subject line. Added benefit is that it is possible to keep communication constrained to a single topic.

Proposed resolution

Remove the restriction that limits threads to sets of users. Optionally, a subject line should be added this is probably not even a necessity.

Remaining tasks

• Agree on approach
• Create a merge request with the necessary changes
• Review
• Merge

User interface changes

No real need, except that multiple threads may appear mentioning the same users.

API changes

Code relying on this module may need to take into account threads are no longer unique per set of user (eventhough they never were, really).

Data model changes

None (?)