memory-check in "slow" release cycle

[j-i-l]

Closes #26

Decision

Since the memory tracking check will most likely exceed the 6h threshold, we cannot simply rely on the free GH runners and need to establish another option.
For the time being we will simply implement an placeholder job that we can correctly integrate into #81 and set up a more complete memory checking workflow, including also furrer-lab/r-containers#29, afterwards.

[j-i-l]

For now these checks run with gctorture and valgrind enabled, however, we might get better results if we use an environment in which R was configured especially for memory checking > see furrer-lab/r-containers#29 (comment)

As far as I understand, we might just switch the container once we have one that is dedicated for memory checking.
I'd handle switching the container in another issue then and focus in this one on the inclusion of the checks suggested in the R docs

[j-i-l]

https://drmemory.org seems to be an interesting alternative to valgrind.

To use it we would need to compile abn with -g -fno-inline -fno-omit-frame-pointer, have the drmemory binary installed and run

drmemory R CMD check  # or similar

[j-i-l]

... let's see how long these tests run.

We might want to run them only on single occasions if they run for several hours. It might easily happen that we have several commits on a release branch.

[j-i-l]

Release Cycle Checks exceeded the 6h limit. ☹️ running with gctorture only now.

[j-i-l]

On option might be to run build with the flags, export the .tar.gz as artifact and then run use a matrix strategy for each file in tests/thestthat/, install abn and run devtools::test_file as we do now with the single example.

[j-i-l]

Memory checks fail successfully! 👍