Don't call the Hub datasets /tree endpoint with expand=True
This puts a lot of pressure on the Hub, and can even break it for big datasets

This is because the Hub gets the lastCommit for each file, and somehow the implementation is sort of n^2 apparently.

Calling /tree with `expand=True` can happen in this cascade of events invoving `hffs` (aka `huggingface_hub.hf_file_system.HfFileSystem`):
1. a dataset without script is updated
2. the config-parquet-and-info job starts
3. data files are resolved using `hffs.glob`
  3a. fsspec calls `hffs.find` and then `hffs.ls` with `detail=True` (even if `glob` has `detail=False`)
  3b. `hffs` calls /tree in with pagination and `expand=True`
4. caching information like ETag are obtained using `hffs.info` in `datasets.data_files._get_single_origin_metadata`
  4a. `hffs` calls `hffs.ls` with `detail=True` on the parent directory
  4b. `hffs` calls /tree with pagination and `expend=True`

One way to stop using `expand=True` in `datasets-server` altogether is to mock `hffs.ls` to not use `expand=True`.

We also need to replace the file information (currently obtained using `expand=True`) in `hffs.info` to not use `expand=True`. This is only used to get the `ETag` to check if a dataset has changed between two commits and possibly reuse generated parquet files but it should be fine. We could use the `oid` instead.

cc @Wauplin @mariosasko for visibility, though it might be too specific to be handled in `hfh` directly
cc @XciD who reported it
Don't call the Hub datasets /tree endpoint with expand=True: This puts a lot of pressure on the Hub, and can even break it for big datasets

This is because the Hub gets the lastCommit for each file, and somehow the implementation is sort of n^2 apparently.

Calling /tree with `expand=True` can happen in this cascade of events invoving `hffs` (aka `huggingface_hub.hf_file_system.HfFileSystem`):
1. a dataset without script is updated
2. the config-parquet-and-info job starts
3. data files are resolved using `hffs.glob`
  3a. fsspec calls `hffs.find` and then `hffs.ls` with `detail=True` (even if `glob` has `detail=False`)
  3b. `hffs` calls /tree in with pagination and `expand=True`
4. caching information like ETag are obtained using `hffs.info` in `datasets.data_files._get_single_origin_metadata`
  4a. `hffs` calls `hffs.ls` with `detail=True` on the parent directory
  4b. `hffs` calls /tree with pagination and `expend=True`

One way to stop using `expand=True` in `datasets-server` altogether is to mock `hffs.ls` to not use `expand=True`.

We also need to replace the file information (currently obtained using `expand=True`) in `hffs.info` to not use `expand=True`. This is only used to get the `ETag` to check if a dataset has changed between two commits and possibly reuse generated parquet files but it should be fine. We could use the `oid` instead.

cc @Wauplin @mariosasko for visibility, though it might be too specific to be handled in `hfh` directly
cc @XciD who reported it