Description

After we've implemented AIP-21 with backport packages and quite recently #10422 "Optimisation of Image building on CI" - we have now an interesting opportunity to speed up the tests even more. Previously each job had 4-10 minutes of overhead which is now down to just 1 minute of image pulling (so it cannot be optimized further). This is very little overhead and now we can have more jobs running in parallel for one job. This might speed up significantly most of our builds.

While the "merges" on master should build the full suite of tests, we can limit the tests run on PR:

1. If core python files change - run all the tests for all backends and versions.

2. If only files from certain provider are changed - run only tests for that provider and all providers that depend on it (we already have all the information to know which providers depend on each other). This can be done only for one backend (and all python versions) - for example, sqlite. Maybe some edge-cases in providers that require mysql/postgres.

With this change, if someone changes only one provider, the tests should run in few minutes rather than hours.

The best is to add another test type "Providers" with different matrix of runs and add custom filtering depending on the files modified by the PR (we already do similar filtering in kubernetes tests). This means we need more jobs (that's why reusing image built only once was so important).

This can be implemented in two steps:

• extracting common composite test run step (which can be used to run all types of tests including the MySQL/Postgres ones) : https://docs.github.com/en/actions/creating-actions/creating-a-composite-run-steps-action
• implement the "Providers" type of test job with filtering only the tests for impacted providers (both direct and dependent providers)

Use case / motivation

Most contributors - only contributing code to providers - should wait less than 10 minutes for the result of their PR build (in terms of elapsed time since the builds starts - there might be some queuing time that we might have no influence on).

Related Issues

#10422 #10959