Cache operations fail when build directory contains a symbolic link

Summary

Build directory path, even if it's absolute, can contain symbolic links. For example, on macOS, /tmp points to /private/tmp.

Build directory path is accepted as is, without resolving the symbolic links in it.

GitHub Runner, for some reason, relativizes the file paths it passes to other components internally, for example, when calling cache-archiver and cache-extractor sub-commands.

Let's say builds_dir = "/tmp/builds" and cache_dir = "/private/tmp/cache".

GitLab Runner calls something like filepath.Rel("/tmp/builds", "/private/tmp/cache") internally and yields ../../private/tmp/cache.

However, accessing this path while being in /tmp/builds will result in ENOENT, because from the OS point of view, we're actually in /private/tmp/builds.

Steps to reproduce

~/.gitlab-runner/config.toml:

[[runners]]
url = "https://gitlab.com/"
token = "..."
executor = "shell"
builds_dir = "/tmp/builds"
cache_dir = "/private/tmp/cache"

[runners.feature_flags]
FF_RESOLVE_FULL_TLS_CHAIN = false

.gitlab-ci.yml:

job:
  script:
    - cat cached.txt || true
    - echo "some info to be cached" >> cached.txt
  cache:
    key: whatever
    paths:
      - cached.txt

Used GitLab Runner version

From main branch.