The organizations table is the basis of a multi-tenant installation.

These models allow us to create tags that have a many-to-many
relationship with Products (via the ProductTags association).

Tags are sequestered within an organization.

It should be the function rather than a constructed instance of datetime
which would effectively be the time when the app started up.

In practice, this default was overriden by the POST or PATCH handlers.

This model stores references to dashboard templates. These templates are
owned by an organization.

This relationship is currently nullable during the migration, but can be
changed to non-nullable later.

This column will replace Build.git_refs, where in practice we never use
the multiple ref feature.

This allows us to identify who uploaded a build.

This enumeration column allows us to classify the edition's kind, which
is useful information for edition dashboards.

Use the version from flask-sqlalchemy rather than the one directly from
sqlalchemy for consistency.

This removes the ForeignKeyConstraint in the most complex version of
https://docs.sqlalchemy.org/en/13/orm/relationship_persistence.html#rows-that-point-to-themselves-mutually-dependent-rows
which was causing us trouble.

This seems to be a better way to handle compound unique constraints?

This is based on https://michaelcho.me/article/using-python-enums-in-sqlalchemy-models
The idea is that the native enum support will store the string value in
the database. It's easier in fact to just store the integer to the DB
and handle the enum at the Python level.

This is necessary for the initial database migration, but can be reset
to be non-nullable once the content can be update.

This lets us run the dev server at the same time as running tox.

In the migration, apply a default value then make the column
non-nullable.

We do this by creating a default organization during the migration and then
updating all products to associate with that default organization.

To fall back to the original LTD API, the new_product() handler gets teh
first organization, which is the default organization created by the DB
migration for the v2 tables.

New installations of LTD, therefore, should use the v2 API in order to
use the organizations feature.

This matches how the v2 table migration automatically associates a
default organization with existing products, but otherwise the
organization feature isn't exposed by the v1 API.

Structlog requires text for the event now.

This order of type checking is correct because InEnum is a subclass of
int.