Commit 868dd8485456ce78a396b687ec7744dc365f06be added a
migration script that caused there to be two heads (starting
points) of migrations which would cause alembic to be unable
to do the initial schema creation (and upgrade).

So this fixes that by correctly making one head only and
not skipping tests for a database if it can not be
upgraded for whatever reason (which was silencing the
test failures).

Closes-bug: #1528683

Change-Id: Id571072eec1dc3b6cbb9e868854f6db0b271e5f8

Change-Id: Ie01ea85e74f1daed6bfa5158c0faa476d06873ba

When a atom is reverted it can be useful to retain the
result of that 'revert' method being called, so that it
can be later analyzed (or used for various purposes) so
adjust the storage, and actions to enable it to be stored.

Change-Id: I38a9a5f3bf7550e924468bb4a86652cb8beb306c

Since this module contains more than the logbook
class and really is a our generic models that are used
to hold the runtime structure it is more appropriate to
place it under a models module and deprecate the usage
of the old module by placing a warning there (so that
when it is imported that warning is triggered).

Change-Id: I79def5ee08f560d38f2c9dcefd0b33becc2a4d36

Instead of implementing a similar version to what the
upgrade function does, just use it directly instead.

Change-Id: I61a3c9f09c6e0724f2b55951989171ef4aaafe0c

The column updated_at does not update its value after the refactoring
made in 687ec913790653f79badc8f5d656c86792e94271.

Closes-Bug: #1457309
Change-Id: Iff45f386b5dc8efc3fe82ca3b1e961a0c23d7ac7

Change-Id: I25686df6a05bf69a89b9b6be169db72eab89d32a

Instead of having constants for lengths that aren't shared among
the table master schema and the upgrade scripts move the constants
that exist in the schema upgrade scripts (which are used to arrive
at the master schema) to use the same constants the master table
schema module uses.

Change-Id: I312760ee329ebd3161c09b316d55afe129ff2d09

We can just simplify the usage of an sqlalchemy if we just use
(we already have our own ORM like objects anyway) sqlalchemy core
in the first place and have a very tiny layer that converts back and
forth from our very limited object model that we use in our
persistence layer.

This change makes that adjustment, which makes it easier to read
and understand the actions the sqlalchemy backend is doing when
saving, reading and updating data, and avoids yet another layer
that isn't useful for our purposes anyway.

Change-Id: I911c509f65e7845aee86fed1622eaa56970741f2