Sanitize dev-container/tunnel file paths to avoid OSError: File name too long in downstream extensions

[edvilme]

Summary

Extensions using this shared package (black, flake8, isort, mypy, pylint) can hit OSError: [Errno 36] File name too long when formatting or linting files inside dev containers via VS Code tunnels. This arises because the fsPath produced from document URIs embeds dev-container netloc components much longer than NAME_MAX (255, often ~350+ bytes), which propagates to tool subprocesses as --stdin-filename or similar arguments.

Background

• Reported in: OSError: [Errno 36] File name too long vscode-black-formatter#735
• Direct fix example: https://github.com/donverduyn/vscode-black-formatter/tree/bugfix/filename-too-long
• All tool extensions using this package currently duplicate fsPath/filename logic and would benefit from a single fix in vscode-common-python-lsp.

Proposed solution

• Introduce a helper (e.g. safe_fs_path_from_uri or similar) to sanitize document URIs, replacing any path component longer than OS NAME_MAX (255) with a fallback using the workspace root (if available) and preserving the filename.
• All downstream extensions should switch to this shared helper.
• Add unit tests with typical dev-container/tunnel URIs as fixtures for regression coverage.

Rationale

• Fixes the root cause for all five downstream extensions in one place.
• Keeps per-extension diffs trivial and prevents future drift or recurrence.

Acceptance criteria

• New helper available in the shared library.
• Black, flake8, isort, mypy, pylint extensions can consume the fix (follow-up PRs to be filed).
• Unit test covers a sample dev-container/tunnel URI exceeding 255 characters.

---

Thanks to @donverduyn for the initial investigation and patch.

---

Originating upstream issue: microsoft/vscode-black-formatter#735