feat: Create fake path for codechecker

[furtib]

Why:
We want the Bazel rule to be as hermetic as possible.

What:

• Added dirname to the toolchain. (This is the only tool we use from PATH. Running codechecker with strace reveals that it accesses openssl and uname too, but they seem to be optional)
• Added a custom PATH containing both the hermetic Python interpreter (even though the script running CodeChecker is a py_binary target, CodeChecker still wants to find Python in PATH) and dirname.

Addresses:
none

Notes:

• We might be able to remove Python from the fake PATH when switching to pip-installed CodeChecker.
  Supporting standalone builds of CodeChecker, however, will still require Python in PATH.

[nettle]

I think we are just missing evidences here (use-case? tests?).
That's why this change does not look convincing to me so far.
Is it a part bigger change?

[furtib]

I'm not sure I understand your concerns.
This is not part of a bigger change.

The main goal of this patch is to move away from using use_default_shell_env = True and get rid of the workaround of setting the PATH to /bin to use system tools.
The use case is to have everything available for codechecker inside the sandbox (just like with clang, and clang-tidy). (In this case, that would be dirname and python)

On the note of tests, since I'm only changing the environment codechecker runs in, any test running a codechecker analysis (e.g.: //test/unit/basic:basic_codechecker_test or //test/unit/basic:basic_per_file_test) should suffice, since codechecker either works or not.

[nettle]

The main goal of this patch is to move away from using use_default_shell_env = True and get rid of the workaround of setting the PATH to /bin to use system tools. The use case is to have everything available for codechecker inside the sandbox (just like with clang, and clang-tidy). (In this case, that would be dirname and python)

OK, it's getting clearer... Thanks for explanation!
So, we get back python toolchain for that :)
But I still dont understand that idea with fake_path... looks kinda clumsy :)

[furtib]

Maybe it's just a naming problem. Since we are creating our own PATH within the sandbox, it might be better to call it something else.

The idea is that CodeChecker will need to find dirname (originally I thought multiple utilities: uname, openssl) in PATH. (I found no way to directly provide the dirname utility for CodeChecker.) So I add the folder containing all tools (in this case, just dirname) to the toolchain provider, add that folder to the PATH, and let the run_files attribute handle the dependencies.