db-migrations: use pg for new migrations

[alxndrsn]

• implement replacement for existing knex migrator

Reviewing

To reduce changeset to non-migrations:

git diff --ignore-all-space master -- $(git diff master --name-only | grep -v '^lib/model/migrations/')

Before merging

Confirm that no (additional) migrations have been accidentally renamed:

git diff --name-status --diff-filter=R master -- ./lib/model/migrations/ | awk '
  BEGIN { renamed = 0 }
  {
    n1 = split($2, a1, "/");
    n2 = split($3, a2, "/");
    if(a1[n1] != a2[n2]) {
      ++renamed
      print "name mismatch: " $2 " vs " $3
    }
  }
  END {
    print "-----"
    print "checked: " NR
    print "renamed: " renamed
    if(renamed > 0) {
      exit 1
    }
  }
'

TODO

• test/db-migrations: don't break on non-JS files in migrations dir #1457
• test/db-migrations: resolve TODO ref migration order #1458
• Remove check-migrations #1398
• update master, resolve conflicts
• use knex table for tracking migrations
• implement knex-style locking in addition to table-level lock
• convert migrations as far back as possible (2023-June onwards) to non-knex
• rename query to raw to simplify migration diffs
• resolve inline TODOs, FIXMEs etc
• rewrite unreleased existing migrations with the new approach (one migration should be introduced by blobs: prevent NULL contentType in db #1355)
• separate PR for connectionObject rename (knex: rename connection object #1364)
• separate PR for connect rename (db-migrate: rename knex-specific functions #1372)
• add eslint warnings for app-level imports into migrations files (db-migrations: prevent new uses of application code #1371)
• fix db migration tests
• move existing migrations to lib/model/migrations/legacy to dissuade creating new knex-based migrations

What has been done to verify that this works as intended?

CI

Why is this the best possible solution? Were any other approaches considered?

Could use slonik instead, but seems better to tie implementation to a lower-level library, especially given concerns about upgrading to a more recent slonik (there are large API changes) and/or possibility of moving to an alternative to slonik.

How does this change affect users? Describe intentional changes to behavior and behavior that could have accidentally been affected by code changes. In other words, what are the regression risks?

Intended effects: none
Possible effects: break production databases

Does this change require updates to the API documentation? If so, please update docs/api.yaml as part of this PR.

Shouldn't require docs changes.

Before submitting this PR, please make sure you have:

• run make test and confirmed all checks still pass OR confirm CircleCI build passes
• verified that any code from external sources are properly credited in comments or that everything is internally sourced