database: Add vitess + mysql 8.0 to our development environment

[beautifulentropy]

The original plan for getting the Vitess infrastructure running was to use vttestserver as a starting point to reach a minimum viable setup. However, vttestserver didn’t work out because some of its defaults conflicted with how we clean up rows and the level of resources (threads) we need.

Fortunately, vttestserver is just a wrapper around vtcombo that generates a vttest protobuf describing the configuration for an in-memory topology server started by vtcombo, encoded in JSON. By modifying vttestserver’s run.sh, we're able to interact with vtcombo directly, passing the JSON configuration along with other vttestserver defaults reverse-engineered from run.sh and vtprocess.go.

Vitess doesn’t provide a vtcombo image, we must build our own. Build and upload a boulder-vtcomboserver image on top of Oracle’s MySQL 8.0 image, which provides native arm64 support. The accompanying tag-and-upload shell script defaults to amd64 for CI.

As an aside, Vitess’s official Dockerfiles are only published for amd64, and modifying them to build for arm64 would prove difficult because Oracle doesn’t publish MySQL arm64 binaries in its Debian apt repository.

With boulder-vtcomboserver up and running I was able to find/validate the following issues and provide workarounds:

• Problem: db-migrate, the tool we use to apply database migrations, must be configured to talk to MariaDB and to MySQL through Vitess (vtgate + vttablet).
  Solution: Create two new dbconfig YAML files (mariadb and vitess) and use test/entrypoint.sh to set the appropriate file for sql-migrate (test/create_db.sh) to use. Also, symlink each of these two new files from db to db-next just like the old dbconfig.yml file.

• Problem: Vitess does not allow database CREATE statements and any DDL containing them will be rejected by vtgate.
  Solution: These databases are already created by vtcombo since they’re defined as KEYSPACES. Skip database creation in test/create_db.sh.

• Problem: Vitess does not allow user creation or grants (CREATE USER, GRANT), and any DDL containing these commands will be blocked by vtgate.
  Solution: Skip user creation and grant steps in test/create_db.sh. Set % for --vschema_ddl_authorized_users as vttestserver does, and revisit this later for a more complete approach.

• Problem: vttablet default for maximum number of rows returned from a (non-streaming) query (10,000) is too low for Boulder’s needs, causing queries to fail due to vttablet rejecting them.
  Solution: Increase --queryserver-config-max-result-size to 1,000,000 and --queryserver-config-warn-result-size to 1,000,000.

• Problem: vttablet default for connection pool size (16) and maximum number of concurrent transactions (20) are too low for Boulder’s needs, causing queries to fail due to vttablet being overloaded.
  Solution: Increase --queryserver-config-pool-size to 64 and --queryserver-config-transaction-cap to 80.

• Problem: Vitess does not allow TRIGGER statements and any DDL containing them will be rejected by vtgate. Without TRIGGER statements TestIssuanceCertStorageFailed, an integration test, will fail.
  Soluton: Run these TRIGGER statements in an entrypoint scripttest/vtcomboserver/install_trigger.sh, bypassing vtgate entirely.

Depends on #8479
Depends on #8489
Depends on #8490
Depends on #8494
Fixes #7736

[github-actions]

@beautifulentropy, this PR appears to contain configuration and/or SQL schema changes. Please ensure that a corresponding deployment ticket has been filed with the new values.

[aarongable]

Overarching comment: I think a bunch of small pieces of this (the sa.go change, the schema file changes, the "put max_statement_time in every dburl explicitly" change, etc) could and maybe should be broken out as smaller changes that precede actually adding Vitess+MySQL8. I don't feel super strongly on this point -- this PR is actually fairly readable despite its size as-is -- but since some pieces have already been broken out, it would make sense to continue down that path.