Speeding up mono-repo CI

[pinkwah]

It seems that the direction of ERT is in that of a mono-repo. If we want to merge more than one PR a day, we need to have a strategy for handling an increased test load.

A suggestion that I think is the most defensible is split test suites and trigger them only when code in paths are changed using https://docs.github.com/en/actions/learn-github-actions/workflow-syntax-for-github-actions#example-including-paths . Maybe as a better alternative, we can mark pytests with the path of code that they modify and programmatically include only the union of paths that are modified. Eg. if only res/enkf is modified, run only the tests/libres_tests/enkf tests.

Each PR should merge towards some sort of staging branch (staging or develop). At midnight, Github Actions should trigger a full test suite run. If this is green, rebase main onto the staging branch.

This would bring the CI run time from an hour to a few minutes for each PR while keeping the main branch somewhat sane.

---

Another thing that I could mention is building of libres.so. Since libres.so is changed seldomly, we probably want to avoid building it for every PR. This takes around 10-15min that is just unnecessary. We can instead use the Github Actions caching functionality to cache libres.so, naming the cached file something along the lines of res-wheel-{libres/ commit hash}.tar.gz. The commit hash in the name makes it possible to detect if we should recompile libres or not.