TKO: provide access to models

The new services we're developing on top of TKO do not consume
all of these models raw data, but IMHO it's better to have all
TKO information available.

Time will tell how much usage they will have.

Signed-off-by: Cleber Rosa <crosa@redhat.com>
tko/autotest-db-delete-job: adjust to new settings API

Signed-off-by: Cleber Rosa <crosa@redhat.com>
scheduler/monitor_db.py: fix typo

So that it does not confuse others as it did confuse myself.

Signed-off-by: Cleber Rosa <crosa@redhat.com>
tko/db.py: optmize insert statements and comply with more strict schema

The schema created by Django+South only (that is, not using the schema
SQL file) is a bit more strict, including having more NOT NULL fields.

But, the TKO parser database code inserts data into the database using
a custom creator of INSERT statements that mentions every single field.
Fields without data contains 'None' which get mapped into NULLs. To
avoid breakage with the stricter schema, simply ommit fields that have
no value (None).

Eventually all this custom code will be removed and will hopefully use
Django's database/ORM layer for all database access, so this kind of
hack won't be needed.

Signed-off-by: Cleber Rosa <crosa@redhat.com>
TKO: add entries needed for the TKO parser/service

Using Django's fixture files, once the custom SQL schema file has
been removed/deprecated.

Also, some unittests needed adjustments because they did not count
on having any initial data (test labels) on the database. And since
the database creation is closer to being identical on production
and when running the unittests, they now have to cope with the
initial data present on the test database.

Signed-off-by: Cleber Rosa <crosa@redhat.com>