Handle ENAMETOOLONG on macOS when clearing cache entries

[woodruffw]

WIP, I still need to clean this up + think about appropriate warning states.

Summary

Fixes #15569.

TL;DR: if a user runs uv cache clean (or similar) but their cache directory contains absolute paths that are pathologically long (longer than PATH_MAX=1024), walkdir will fail to materialize them before we have a chance to actually delete them.

The solution is to take their parent directory and remove each member relative to it. Rust's remove_dir_all does this robustly by using openat and unlinkat on macOS.

I think we could probably broaden this to Linux (and other Unix-likes?) as well. However the problem is less apparent there since PATH_MAX is even more pathological (4096).

I decided not to add a user warning here, since it's not really actionable.

Test Plan

Added integration tests.

[astral-sh-bot]

uv test inventory changes

This PR changes the tests when compared with the main base revision.

• Added tests: 3
• Removed tests: 0
• Changed suites: 1

uv::build: +3 / -0

Added:

• uv::build::cache_long_paths::clean_handles_overlong_file_paths
• uv::build::cache_long_paths::clean_handles_overlong_paths
• uv::build::cache_long_paths::prune_handles_overlong_paths

Removed: none

[woodruffw]

NB: I suspect BurntSushi/walkdir#217 is what we'll want longer-term here.

[EliteTK]

I'm not too fond of this kind of a workaround.

walkdir is a bit too established for an upstream fix to land in a way which would cleanly help here. I think a perfectly reasonable decision is to just write our own small walker for our purposes which gives you entries in a form which makes it easy to manipulate without needing to deal with long paths (of course for logging we'd still need to construct a path, which we can still do). I wouldn't mind fixing this (sounds like fun).

This PR does have two gaps though:

• uv_distribution::prune: called for the sdists bucket, uses walkdir without this guard, since we extract into a shallower path and then rename, there's a chance we could still construct paths that end up too long.
• find_archive_references: called for the sdists and wheels buckets, uses walkdir without this guard, but it skips src directories and thus is probably not realistically going to have an issue because of this.

[woodruffw]

Yeah, it's kind of a sad workaround.

walkdir is a bit too established for an upstream fix to land in a way which would cleanly help here.

How do you mean? I think that PR linked above would address our specific problem, although it does involve a public API break on walkdir's side.

[woodruffw]

I'll see if I can lift the changes further here; I agree at minimum we should be guarding the prune case too.