Add a basic precice test suite (and rename release_test)

[MakisH]

Description

This PR adds a basic precice test suite, meant to run always on PRs in the preCICE repository. I selected cases that are rather short and cover a range of features:

  precice:
    tutorials:
      - *quickstart_openfoam_cpp                                                 # serial-explicit, RBF
      - *channel-transport_fluid-openfoam_transport-nutils                       # parallel-explicit, RBF, python bindings
      - *flow-over-heated-plate_fluid-openfoam_solid-openfoam                    # serial-implicit (Aitken), nearest-neighbor
      - *flow-over-heated-plate-nearest-projection_fluid-openfoam_solid-openfoam # serial-implicit (IQN-ILS), nearest-projection
      - *elastic-tube-1d_fluid-cpp_solid-cpp                                     # serial-implicit (IQN-ILS), nearest-neighbor
      - *partitioned-pipe-multiscale_fluid1d-left-nutils_fluid3d-right-openfoam  # parallel-implicit (IQN-ILS), axial-geometric-multiscale

Example run: https://github.com/precice/tutorials/actions/runs/26751220367

With cached components, this test suite takes < 5min to run.

Checklist

• I added a summary of any user-facing changes (compared to the last release) in the changelog-entries/<PRnumber>.md.

[uekerman]

I like the idea. "always on PRs" means that this runs for each "push", correct?

My first thought: Could we move the testcases more from "testing preCICE features" to "testing compatibility"? For the preCICE features (RBF, IQN-ILS, ...), I think that the integration tests cover a lot already. C or Fortran bindings could be interesting, e.g. CalculiX adapter.

We now already have a bit of experience with the system tests. How did they fail in the past? Which component was the problem? We should try to catch these as early as possible.

[MakisH]

"always on PRs" means that this runs for each "push", correct?

yes, exactly. Similarly to the build and test workflow.

My first thought: Could we move the testcases more from "testing preCICE features" to "testing compatibility"? For the preCICE features (RBF, IQN-ILS, ...), I think that the integration tests cover a lot already. C or Fortran bindings could be interesting, e.g. CalculiX adapter.

I can add the elastic-tube-1d with Fortran and the CalculiX adapter. In any case, we have caught a couple of numerical regressions in the system tests that were not previously caught in the unit/integration tests, so I also see this as a way to discover blind spots in the earlier tests.

We now already have a bit of experience with the system tests. How did they fail in the past? Which component was the problem? We should try to catch these as early as possible.

Besides the various issues with the tests/infrastructure, many of which have been fixed (related to network/storage, for example), some were originating from changing dependencies (e.g., Numpy 2), and some from changes in the implementation that led to different (but not necessarily worse) results, mainly in the mapping and the issue we had with the preconditioner in ?v3.1?.

Most importantly, for me, this would act as a reminder to update adapters and tutorial cases.