Comment 3 for bug 290657

I started working on this, but I choose to revert because the there are complications. I think someone with good knowledge of how recipient sets work can fix this issue in a days work. While we can send a copy of a message to the sender easily, the header and footer will before for someone else -- the reason and header rationale must be correct, otherwise new bugs are introduced.

The are user-to-user views doctest should be replaced with a unittest because small changes to the classes topples the doctest. ContactViaWebNotificationRecipientSet redefines a lot of normal behaviour that we want to restore. It currently only allows us to add the user or team that is being contacted. It generates all the recipients, rationales, and reasons exactly once. You cannot add another recipient, which is what we want to do in the case of the sender. One way to do this is to generate the recipient dict and allow code to later extend it. It needs to check of the recipient is also the sender, which is a little tricky because recipient sets work with preferred email addresses, so the selected email address must be known to the recipient set. Maybe we want to remove the choice of addresses.

There are two corner-cases that ContactViaWebNotificationRecipientSet needs to resolve:
1 Where the user contacts himself, does he get two emails with different rationales?
2 where the user is a member of the team getting the email, doe he get two emails or do we change rationale to from recipient to sender?