get_node has a fallback mechanism for dealing with emails that are sent without a node 
identifier in the subject line.


  1. get the message-id from the in-reply-to header (skip this if no in-reply-to header)
  2. find the ID associated with the message-id in the msgs store.
  3. find the ISSUE_ID for the issue that has the ID in its message list
  4. use that ISSUE id as the node identifier

If step 2 returns a list of ID's rather than just a single id, I think this will crash.

One use case for having the same message on multiple issues is to group issues
such that a issue is a member (child issue) of a group of issues associated with another 
(group parent, aka parent) issue.

When an update is done to the child, the message is also placed on the parent activating its 
nosy list. When the update is done on the parent, it can be propagated down to the grouped 
child/children to notify them. Think of it like a limited broadcast across the group.
This is an alternative to merging issues.

I think the thing to do is check to see if there is more than one issue returned in 2,
and if so pretend like we didn't have an in-reply-to header in the first place. There is
no sensible way to determine which issue is the original issue that triggered the reply.

I set priority/severity to normal because this requires a specifically designed tracker
using message multi-propagation to trigger the problem.

Changed code so that:

  if in-reply-to returns more than one issue
  use Subject matching to find matching issue
    (if multiple matches it chooses the newest/last in list)

Hopefully the Subject match will be more accurate in determining
the issue that received the original (parent) message.