update hffilesystem docstring

[lhoestq]

it was referring to overheads that don't exist anymore

I think it was about file streaming and copying files but that have been optimized some time ago:

• Fast download in hf file system #2143
• [HfFileSystem] Copy non lfs files #1996

Regarding the point on reliability, I think it was related to the caching mechanism mentioned here: #2643 but lmk what you think

[HuggingFaceDocBuilderDev]

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

[Wauplin]

Even though we've fixed some issues on the most important aspects (hf_transfer, efficient copies, etc.) it is still true that using fsspec adds some overhead since there is the abstraction layer on top of HfApi. It's not that I want to discourage people to use it when they need fsspec API compatibility but for day to day usage I still think it's best to push for HfApi.

(basically with HfApi we "own" all the Python stack, with HfFileSystem we delegate part of it to an abstraction layer which necessarily adds complexity when debugging)

[lhoestq]

I'm a bit hesitant in keeping "overhead" as is since it's pretty vague. Maybe it would be best to clarify which HfFileSystem operations are different with HfApi and why. For instance HfFileSystem is better suited than HfApi to stream files or remote random access (since HfApi doesn't have such a feature IIRC), but is less suited for git operations (it does one commit per upload). What do you think ?