Path resolve, running on different sandbox levels; why does ccache work on docker

[furtib]

Describe the bug
Resolution of softlinks in plist files in the codechecker rule fails, depending on the sandbox level used by Bazel.
With certain files (header files, but there could be examples with source files too), the path left in the list file is completely wrong; it looks something like this: bazel_codechecker/bazel-out/k8-fastbuild/...

Versions

• CodeChecker 6.26
• bazel 6.5.0
• on branch: furtib:fix_plist_paths commit: 19600a9

To Reproduce
To reproduce, try:

bazel build //test/unit/virtual_include:codechecker_virtual_include  --spawn_strategy=processwrapper-sandbox

Then, examine the generated list files.

Script to set up from scratch:

git clone https://github.com/furtib/codechecker_bazel.git
cd codechecker_bazel
git checkout 19600a9ada385e073c3ff32df9af0d11a0dafd7d
USE_BAZEL_VERSION=6.5.0 bazel build //test/unit/virtual_include:codechecker_virtual_include  --spawn_strategy=processwrapper-sandbox

Expected behaviour
I expected the path to be resolved to the original file

Additional context
Docker images use processwrapper-sandbox while local machines use linux-sandbox by default.
It seems that the linux sandbox is unavailable in Docker runners. See: https://bazel.build/docs/sandboxing#:~:text=Both%20the%20linux%2Dsandbox%20and%20the%20darwin%2Dsandbox%20do%20not%20work%20in%20a%20%22nested%22%20scenario%20due%20to%20restrictions%20in%20the%20mechanisms%20provided%20by%20the%20operating%20systems.%20Because%20Docker%20also%20uses%20Linux%20namespaces%20for%20its%20container%20magic%2C%20you%20cannot%20easily%20run%20linux%2Dsandbox%20inside%20a%20Docker%20container