Road to great justice for schedulerdb!

Test cases

Description	Manually tested?	Automated test in place?	Notes
Builds should happen after a checkin
Nightly en-US build should trigger repacks after build is done
Change to locale repo should trigger a single repack
Nightly builds should get fired	[DONE]
Release l10n repacks should get fired
Queued changes / builds are restored after restarting buildbot master	[DONE]
Multiple masters can share the same database for the same builders
Test that sendchanges between masters is working	sendchange to localhost is working
Test that nomerge changes aren't getting merged (e.g. talos runs, unittest runs, l10n repacks)

Timeline

March 1st-12th
- deploy new python, twisted toolchain on staging master
- deploy current buildbot tip on staging master and slaves, start testing current patches (see test cases to exercise above)

March 15th-26th
- deploy new python, twisted toolchain on talos staging master
- deploy current buildbot tip on talos staging master and slaves, start testing current patches

April 1 Buildbot 0.8.0 release or backporting of db features to 0.7.12+
- would only backport to 0.7.12 if 0.8.0 takes too long to release

April 6 Deploy buildbot, python, twisted onto production build masters and slaves
- Slave upgrade isn't strictly necessary to do, but feels right thing to do.
  - has the potential to break builds (if e.g. part of build doesn't work with python 2.6). If needed, we could isolate build tools from system tools.

April 13 of buildbot onto production talos masters and slaves
- Python / twisted upgrade on production talos masters (going to python 2.6.4, twisted 9.0.0 or 9.0.1).

The current try server code doesn't need to be touched, since all that code is going to be integrated into the main configs, which should "just work".

Talos can be handled later if required. Its scheduling is pretty straightforward. It's also a good piece to test in parallel with the build bits.