Merge lp://staging/~gary/launchpad/bug741684-3 into lp://staging/launchpad

[r=bac][bug=741684,742230] Further optimize the notification script code.

This branch changes how we get filter information for each email recipient one more time. Now, instead of making a query per subscription source, we make a single query for an entire batched set of notifications. We then assemble the data into the structure we actually want per recipient.

Part of the structure of the new method, and how it is used, is coming from the fact that I'm preparing to add additional functionality to it in a db-devel branch, but I think it stands up well enough on its own.

Almost all the code in this branch is about that change, either directly or indirectly (tests).

The only exception is that lib/lp/bugs/scripts/bugnotification.py also contains some changes because I was tired about being confused about the "recipients" name. The notification.recipients collection is actually a collection of objects that describe the subscriptions that will be affected by the notification. Each "recipient" has more information than just the principal involved in the subscription (including the rationale, for instance) and also, in this script, the "recipients" are exploded out into the people who actually receive the emails. Therefore, while the "recipients" collection on each notification makes some sense as a name on the notification, it was getting confusing within the script itself. I decided to call these objects "sources" and the people who would actually receive the mail "recipients".

I would have preferred to have getRecipientFilterData be a function for simplicity, but in this case it was actually nice to have it on a utility so I could use dependency injection within one of the tests. That said, given that there's no machinery to automatically undo the utility registration, it is interesting to note that there's no practical advantage to this pattern over monkeypatching, which is a bit sad.

Thank you!