Merge lp://staging/~gary/launchpad/bug548-db-3 into lp://staging/launchpad/db-devel

[r=bac][ui=none][no-qa] Add "selfgenerated_bugnotifications" as a global option for people so that we can work on bug 548. Only in the DB at this time, since the actual implementation is not yet done.

This branch fixes the remaining test failures from wgrant's branch (fixing most of the failures) of my previous branches. It also reinstates the use of a test helper for one file (bugnotification-sending.txt) that wgrant reverted because I believe it is an improvement and I don't see a reason to lose it. He probably reverted it because it was unnecessary to get the tests to pass, which is absolutely true. These changes have already been reviewed and approved (https://code.launchpad.net/~gary/launchpad/bug548-db-2-tests/+merge/48570).

This branch had to fix three sorts of test failures. First, I had hoped that we would be able to make the person-specific settings simply not implemented for teams. This proved to be untenable: at least two automated interface-based functions (verifyObject from zope.interface and lazr.lifecycle's snapshot functionality) crashed and burned by this behavior. Therefore, I opted to make the attributes readonly for teams, using the defaults from the interfaces. I had a mid-implementation call with Danilo about how to tackle that. I want to do what you see here, rather than a __getattr__/__setattr__ approach or a manual approach. I don't think that the __getattr__/__setattr__ approach is potentially better than this, but I was somehwhat tempted by the manual approach. My arguments against it were these.

 - This way keeps you from having to repeat yourself (again) by explicitly listing the attribute names.
 - We expect to add many more attributes to this settings bag, and setting up each one manually in a readonly version would be a drag.
 - We expect to add a team-based settings bag, and repeating things there would be even more of a drag.

Danilo thought that my preferred approach was acceptable, so I proceeded.

The second test failure was in garbo, cleaning up people. This was simply addressed by teaching it about the new person settings table (that it is safe to ignore it when trying to determine whether a person is still linked).

The last test failure was that ImmutableVisibilityError was being raised because Person.visibilityConsistencyWarning needed to be taught to ignore person settings too.

My goal is to get this landed asap to try and make it into PQM. I'd prefer having to make "I'll fix that next" promises if possible, rather than significantly holding up the branch, but I will understand if you are not comfortable with that.

Thank you

Gary