Sanitize symlink target

[e3krisztian]

Split off of #763 . There are still problems to solve here, see 954c1cd#commitcomment-138623089 but tests should run with the exception of 2 failures.

954c1cd rewrites the logic to sanitize symlinks to be relative and kept within the extraction directory. This is done using the os module instead of Pathlib as Pathlib.resolve would fail if a symlink target was missing (which doesn't prevent us from safely converting it to a relative link). With this change I no longer see false positives around MaliciousSymlinks, instead symlinks are created safely within the extraction directory. If a relative symlink originally tried accessing a directory above its own root (i.e., ./bin/sh -> ../../../../../bin/bash), we update the link so it remains within the extraction directory.

[qkaiser]

I'll mark the PR as draft until ruff is back and we have a cleaner view on what are the logic changes being applied.

[AndrewFasano]

I believe there is still a bug in b11fe46: when extracting in a (host) directory within /tmp/, a symlink of /var pointing to /tmp/var will be sanitize to point to var creating a symlink loop. This seems to be caused by the use of os.path.commonpath finding a similarity between the extraction directory and the absolute symlink target.

[e3krisztian]

@qkaiser I wanted to make this PR just to have a place to discuss. It was extracted from a larger PR, and wanted to see CI test results, which our code checks (ruff) prevented, to push through the commit I have made some hacky fixes to be thrown away in the final version.

This definitely needs a rewrite, so should have made it draft initially.

I do not plan working on this soon, especially as the tar fix covering these problems are merged.