No longer overwrite slow-checks.yml

[ArBridgeman]

Summary

In discussing #825 with @tkilias and @ckunki, we've decided that we'd like for the maintenance of slow-checks.yml to change from being maintained by the PTB to instead be maintained by the users in a specific project.

We would when a project is first created provide our default slow-checks.yml and then no longer overwrite it.

Discussion

The reason behind wanting to shift the maintenance to the project is that currently slow-checks.yml throughout the projects using the PTB have a variety of setups:

• different OS / runners:
  • most use the default ubuntu
  • some tests use GPU → these are costly and maybe shouldn’t be run with periodic-validation
• different databases:
  • not use any databases
  • use Exasol Docker databases
  • use a SaaS database
• different Python versions:
  • some projects run from Python3.10 - 3.13
  • others will just run for 1 Python version
• the differing Python version and databases lead to different needs and difficulties:
  • the matrix-all job may be correct or incorrect → the PTB does not support different matrices yet nor can a user replace a job
  • the resulting coverage file (which must be uniquely named by default) may be poorly formed
  • the run-integration-tests default value can be replaced but it’s limited by the previously mentioned factors

Given all these differences, it seems foolhardy for us to make users wait until we have the perfect fix. It would also take a lot of time.

To Dos

• Update the code underlying in workflow:generate to have a list of workflows that we don't maintain. Currently, this would just be the slow-checks.yml, but it's better if we have it in a generic form than hard-coding it.
• Ensure that if a project is newly created, that the slow-checks.yml from the templates is added
  • Check if we have a test covering this (think we do) and verify it sufficiently covers this use case
• Ensure that if a project is already existing that the slow-checks.yml is NOT modified by the PTB
  • Add a test for this
• As the original file comes from the PTB, perhaps it's useful in the logs to say that it is skipped, at least on the DEBUG level.
• Modify the documentation - perhaps by adding another section for expected workflows that we do not maintain in the PTB - to clearly state where the responsibility lies