feat(testing): Add dummy-io simulation support for zero-data-transfer benchmarking and testing

[raj-prince]

Summary

This PR introduces a Dummy I/O Simulation Suite (DummyGcsFileSystem, DummyMRD, DummyMRDPool, DummyDelaySimulator) within gcsfs/tests/ to simulate read operations against Google Cloud Storage without performing real network data transfers.

Motivation: Deterministic Offline Benchmarking - Measure application CPU bottlenecks and I/O concurrency independently of network fluctuations.

---

Usage Instructions

1. Direct Instantiation in Python Scripts

Instantiate DummyGcsFileSystem directly and pass simulated latency/bandwidth limits:

from gcsfs.tests.test_dummy_io import DummyGcsFileSystem

# Instantiate with 2ms TTFB latency and 1500 MB/s simulated bandwidth
fs = DummyGcsFileSystem(
    dummy_io_ttfb_ms=2.0,
    dummy_io_bandwidth_megabytes_per_sec=1500.0,
)

# Metadata is retrieved from real GCS, but reads return zeroed bytes with simulated timing
with fs.open("my-bucket/large_file.bin", "rb") as f:
    chunk = f.read(32 * 1024 * 1024)  # 32 MB
    print(f"Read {len(chunk)} simulated bytes")

---

2. Transparent Integration via fsspec

For downstream libraries (e.g., PyTorch DataLoader, Ray, Pandas) that use fsspec.open("gs://..."), register DummyGcsFileSystem globally without modifying application code:

import fsspec
from fsspec import register_implementation
from gcsfs.tests.test_dummy_io import DummyGcsFileSystem

# Register DummyGcsFileSystem to handle 'gs://' and 'gcs://'
register_implementation("gs", DummyGcsFileSystem, clobber=True)
register_implementation("gcs", DummyGcsFileSystem, clobber=True)

# Standard fsspec calls will now use the zero-egress dummy read path
with fsspec.open("gs://my-bucket/dataset.tar", "rb") as f:
    data = f.read(64 * 1024 * 1024)

---

3. Environment Variable Configuration

Simulation parameters can be configured dynamically via environment variables:

Environment Variable	Type	Default	Description
GCSFS_DUMMY_IO_TTFB_MS	float	0.0	Initial Time-to-First-Byte latency in milliseconds.
GCSFS_DUMMY_IO_BANDWIDTH_MEGABYTES_PER_SEC	float	None (unlimited)	Streaming bandwidth limit in Megabytes per second (MB/s).

export GCSFS_DUMMY_IO_TTFB_MS=5.0
export GCSFS_DUMMY_IO_BANDWIDTH_MEGABYTES_PER_SEC=1000.0

python your_benchmark_script.py

[gemini-code-assist]

Code Review

This pull request introduces a dummy I/O mode for gcsfs to simulate read operations without network data transfer, allowing users to simulate latency and bandwidth delays. The review feedback highlights several critical issues in the implementation: a missing weakref import, a potential resource leak due to an unregistered finalizer when overwriting _mrd_pool_cache, a parameter name mismatch with the parent class, a unit mismatch where megabits are treated as megabytes in delay calculations, and significant code duplication in DummyMRDPoolCache.get that could be refactored.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.02%. Comparing base (18afe60) to head (248fc37).
⚠️ Report is 29 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1020      +/-   ##
==========================================
+ Coverage   89.68%   90.02%   +0.33%     
==========================================
  Files          16       16              
  Lines        3579     3650      +71     
==========================================
+ Hits         3210     3286      +76     
+ Misses        369      364       -5     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[ankitaluthra1]

Please fix the patch codecov failure

[ankitaluthra1]

Consider moving DummyDelaySimulator, DummyMRD, DummyMRDPool, and DummyGcsFileSystem entirely out of the main package and into the test suite (gcsfs/tests/). Can see if possible to use Dependency Injection or unittest.mock.patch within your test files to swap out the production filesystem or MRDPool with your mock during test execution, rather than altering gcsfs/init.py to conditionally load a dummy file system. Adding "dummy" or "mock" classes to production code is an anti-pattern which we should avoid if possible.