deployment report should fail revisions in stable containing undeployed db changes

[Stuart Bishop]

A revision in launchpad/stable should be flagged as bad if it contains database changes that have not previously landed in launchpad/db-stable.

'database changes' means any change to database/schema/*.sql, including addition or removal of files matching this pattern.

[Stuart Bishop (stub)]

Once this is done, the losas can remove the PQM guard blocking database landings on launchpad/devel. This will allow devs to merge db-devel into devel rather than requiring losas to do it.

[Stuart Bishop (stub)]

I'm not sure if this logic is right. We don't care if db changes have previously landed in db-stable. We care that they have been deployed.

[Stuart Bishop (stub)]

db patch to store bzr revisions used to make updates has landed. Next up, patches to update.py to maintain these fields.

Once we have the information available in the database, we can export it (probably as a json blob served from launchpad.net).

Then the qatagger has the information it needs to determine what should and shouldn't be merged.

[Stuart Bishop (stub)]

The data is in the database in the LaunchpadDatabaseRevision and LaunchpadDatabaseUpdateLog

[Stuart Bishop (stub)]

Ignore LaunchpadDatabaseUpdateLog - it will be disappearing. It is only needed to track non-db patch changes like stuff altered in trusted.sql and we are stopping doing that.