feat: Support for specifying multiple databases in test macros.

[masato-hi]

This makes it possible to specify multiple databases with the sqlx::test macro.

Adds grouping by env and specification of environment variable names by var as macro arguments.

This makes it easier to write tests for the following cases:

• Sharded databases

• Multiple types of databases (for example, the case below).

  • Uses Sqlite as local master data and stores variable data in remote PostgreSQL.

  • A relational database and a relational-compatible NoSQL database.

Concerns

Are the argument names env and var ambiguous?

Other changes.

• Added TestArgs::no_migrator to simplify macro implementation.
• Added TestArgs::database_url_var to save the environment variable name when running tests.
• Added cleanup_test_dbs_by_url function to TestSupport, which deletes test databases from the database_url argument.
• Added a macro to implement test functions that support multiple databases.
  • It is possible to replace the existing TestFn with a macro, but this is not done as this is intended to be a reference implementation for macro implementation.
• Modified MASTER_POOL during testing so that it is retained for each environment variable name.
• Changed to display the database name created during PostgreSQL testing.
  • It was displayed in MySQL, so I changed it, but is that okay?
• Added a test for using multiple databases for CI.

Does your PR solve an issue?

closes #2220
closes #3947

Is this a breaking change?

Yes.

TestSupport::cleanup_test will be changed to take TestArgs as an argument.

[abonander]

Any APIs that are only exported from sqlx-core and not sqlx are considered SemVer-exempt and so major changes to them are not breaking for versioning purposes.

I say that because this is unlikely to land in 0.9.0 as I'm really trying to fight feature creep because otherwise I'll never get it out the door.

[masato-hi]

Any APIs that are only exported from sqlx-core and not sqlx are considered SemVer-exempt and so major changes to them are not breaking for versioning purposes.

I agreed that this is a non-breaking change because the API is not used by general users.

I say that because this is unlikely to land in 0.9.0 as I'm really trying to fight feature creep because otherwise I'll never get it out the door.

What should I do?

• Wait until we can celebrate the release of 0.9.0.
• Close this PR and re-implement it after the 0.9.0 release.
• Implement it as a change to 0.8.x.

[abonander]

This PR can stay as-is, I was just letting you know that I might take a while to review it properly.