fix(drop): drop an auto-populated table's jobs table with it

[dimitri-yatsenko]

drop_quick() dropped only the table itself, so drop() left an
auto-populated table's jobs table, ~~<table_name>, in place with its
records and its primary key. A table later declared under the same name
picked it up through its jobs property. When the new primary key was
wider, populate(reserve_jobs=True) computed nothing and raised nothing:
the old records, keyed on part of the new primary key, covered every new
key.

drop_quick() now drops the jobs table of a Computed or Imported table
after the table itself. drop() reaches each table as a FreeTable, so the
tier is read from the table name, as Schema.jobs does. A Manual or Lookup
table never drops a jobs table, though a Manual result and a Computed
__result map to the same ~~result. The jobs table is itself dropped
through drop_quick(), so its ~lineage rows and, on PostgreSQL, its enum
type go with it.

Jobs tables left by earlier releases remain, so the jobs property now
checks an existing jobs table's primary key against the one it would be
declared with, and raises if they differ, naming the jobs table and the
command that removes it. Job computes its foreign-key-derived primary key
once, so a table with a primary key attribute of its own still logs the
"Ignoring non-FK primary key attribute" warning once per access.

The tests run on MySQL and PostgreSQL. In the issue's reproduction,
drop() removes ~~result and its lineage rows, and the table declared
again with a wider primary key populates all six keys. drop_quick()
removes ~~result too, with its enum type on PostgreSQL. Dropping a Manual
table leaves the Computed table's ~~result in place. A jobs table left
behind by a plain DROP TABLE makes jobs raise; the command in the message
removes it, and populate then completes. A table with a primary key
attribute of its own passes the check and warns once.

Closes #1601.

[dimitri-yatsenko]

Holding this as a draft: on PostgreSQL it would make an existing data-loss bug much more likely.

drop_quick() drops a table's enum types with DROP TYPE ... CASCADE. Enum types are named by their values and shared across a schema, so the CASCADE also drops every other column that uses the same enum, with its data. Every jobs table's status column has the same enum, so with this PR, dropping one auto-populated table also drops status from every other jobs table in the schema. Checked on PostgreSQL: after A.drop(), ~~b has no status column.

The enum fix goes in first, in its own PR; this one goes back to review after that.