Add support for rm_file in GitHubFileSystem implementation

[mecit-san]

This PR adds support for the rm_file method in the GitHubFileSystem implementation of fsspec, enabling file deletion using the GitHub REST API.

The GitHub API for managing file contents requires:

• A commit message for each action (add/update/delete), similar to editing files via the GitHub web interface.
• The SHA of the target file’s latest version when deleting or updating, to avoid race conditions.

This implementation adheres to those requirements, making rm_file work reliably for GitHub-backed filesystems.

Note: This PR focuses solely on file deletion. I plan to follow up with a separate PR to implement the remaining methods and functionality (e.g., adding file, updating file, etc.) for full GitHubFileSystem support.

Fixes #1836

[martindurant]

Looking generally good.

[mecit-san]

Thanks for the review, @martindurant.

By the way, based on merge workflow, it seems that initializing the filesystem with incorrect credentials (mock data) behaves differently in Python 3.10 compared to other versions — it raises an authentication error. Since this issue doesn't appear to be related to the rm call, should we consider removing this test or handling it differently? 🤔

fs = fsspec.filesystem(
    "github", org="mwaskom", repo="seaborn-data", username="user", token="token"
)

[martindurant]

You mean as opposed to NotFound? The test can be version-specific if need be.

[mecit-san]

This is the line where the test fails due to a 403 error:

fs = fsspec.filesystem(
    "github", org="mwaskom", repo="seaborn-data", username="user", token="token"
)

The error occurs when attempting to retrieve the SHA inside __init__, using the provided token.

At first, I suspected the issue was related to the Python version, since the failure only appeared under Python 3.10 test workflow. However, after running the same test locally using Miniconda with Python 3.10, it passed without issues.

I now believe the failure is due to GitHub rejecting unauthenticated or invalid-token access to certain endpoints. This can happen if the API rate limit for unauthenticated requests has been exceeded.

@martindurant

[martindurant]

I suppose it's fine. We can add more docs around it if people start noticing this. Particularly around the new delete (and write) functionality, we don't expect anyone to come with an invalid token!