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

Prefer the non-deprecated 'oslo_serialization' instead of
the namespaced 'oslo.serialization' wherever it was previously
used.

Change-Id: I652cf0b56e28d727c59fe0c060949bb2bd920d11

Prefer the non-deprecated 'oslo_utils' instead of
the namespaced 'oslo.utils' wherever it was previously
used.

Change-Id: I9a78150ef5266e1ff22147278162fe3cfe1b2e3f

The reflection module is now part of oslo.utils so we should
remove our local version and use that version instead; this
also goes for the uuidutils module which is now part of
oslo.utils as well so we no longer need our local version
copied from the incubator...

Note that one reflection method `find_subclasses` which was to
specific to taskflow is now moved to the misc utility module
instead of its prior home in the reflection module.

Change-Id: I069881c80b0b2916cc0c414992b80171f7eeb79f

Instead of copying modules from the incubator into taskflow
we can now directly use these same modules from supported
libraries instead so this moves the usage of everything except
uuidutils which wasn't moved over to using those newly published
libraries.

Part of blueprint integrate-and-use-oslo-utils-serialization

Change-Id: I1183bda96e1ddb062d9cab91990186f0f56f0a0e

* H305  imports not grouped correctly
* H307  like imports should be grouped together

Change-Id: If1dd9c89f65ede6959865a885777cb08c263eca0

- Convert the various functions that take a task detail into
  ones that take atom details (since this is now the generic
  type they should take).
- Don't expose the detail type strings as part of the atom
  detail api, leave those as private hidden strings and provide
  conversion functions from string<->class instead.
- Have the logbook objects contain the following new methods
  to reduce the dependence on persistence_utils to do the same.
  - to_dict() which converts the current object into a dict
  - from_dict() which converts the provided dict into a object
  - merge() which merges a incoming objects data with the current
    objects
- Have the persistence backends + storage + action engine use these
  new methods instead of there current usage.
- Don't compare to logbook.RETRY_DETAIL or logbook.TASK_DETAIL since
  python has the isinstance function just use it (ideally we should
  fix the code so that this isn't even needed, usage of isinstance
  means something is not designed/structured right).
- In storage tests we can't assume that failures will be non-lossy
  since under certain backends when a failure is stored information
  about the internally held exc_info is lost, so take this into
  account when testing by using matches() where applicable.

Change-Id: Ie8a274cfd4cb4e64e87c355dc99d466d74a4e82c

Change-Id: Ib0f065b02e053ca6dd176eb8d6a75cf71e0982d0