We hit some confusing issues when running selective Review Board test suites with the introduction of registry-backed SCMTools. Basically, when exclusively running certain test suites (ones that do not use the `test_scmtools` fixture on the class level, but do add it for selective tests through the use of `@add_fixtures` -- for instance, `./reviewboard/webapi/tests/test_review.py`), we'd end up in a state where the fixture would try to apply on top of tools injected into the database through the registry. This is actually more the "correct" behavior, as opposed to `test_scmtools` applying on top of nothing, but it's the case that broke tests. The problem has to do with registry setup, when the registry adds to the database, and when fixtures load. The process is this: 1. The first thing a test suite does is call Django's `setUpClass()`, then load class-defined fixtures, then call `_fixture_setup()` (which we override to compile and load fixtures -- too late and redundant on modern Django), and then `setUp()`. 2. Any `test_scmtools` fixtures are injected in Django's `setUpClass()`. This gives us a common database entries used by all tests in the suite (using transactions/rollbacks to get back to that state). If that fixture is not used, no entries will be in the database for these tests. 3. We register some test tools in our own `setUpClass()`, which triggers registry population. If `test_scmtools` was used, this does effectively nothing (though it will register entrypoint-provided tools). If it was not used, then this will inject its own common `Tools` entries in the database. 4. We then get to our `_fixture_setup()`, which used to be where Django managed fixtures on a per-test basis. Djblets overrides this to do fixture compilation and loading (which doesn't work as well with modern Django) and loading of anything provided by `@add_fixtures()`. Once again, any fixtures are loaded and injected into the database. If `test_scmtools` is used here, this is almost a no-op, as `loaddata` (which loads the fixtures) will ignore any identical matches in the database. If `test_scmtools` is not used on the class level, nothing happens here. So far, things are fine. The registry, `setUpClass()`, and `_fixture_setup()` play nice. 5. Now we get to `@add_fixtures()`. This will try to incrementally add the fixtures to the database. If used on a test function, the `_fixture_setup()` for that call will load in any fixtures provided. If we use `test_scmtools` here and on the class level, nothing happens, since `loaddata` will see the data is the same. However, if the initial state was populated by the registry, this will fail, as the data won't match up. It'll conflict. There's a bit of a chicken-and-egg problem here. Confusing, but the solution is to treat our registry as the source of the fixture: 1. The `test_scmtools` fixture is now empty. The fixture itself must remain for compatibility reasons, but it no longer needs content. It's simply an identifier. 2. The SCMTools registry has a new function for the database population, called `populate_db()`. This is still called by `populate()`, but we're able to use it to force a re-sync of tools. 3. `TestCase.load_fixtures()` (called by `_fixture_setup()`) now looks for `test_scmtools`, removes it from consideration, and then tells the registry to populate via `populate_db()`. This gives us one source of truth, and one place (`setUpClass()`) to manage suite-wide population of registered SCMTools.