Add filesystem abstraction to enable deterministic in‑memory testing

[hhalex]

Hello,

thanks for your great work. I am using Fjall for a blockchain protocole, and i use Turmoil to battle test it.

Is your feature request related to a problem? Please describe.
I want to run fjall-backed components inside turmoil (the Rust network/clock simulation framework) for deterministic, fast, and fully in-memory integration tests. Today fjall assumes std::fs/real filesystem I/O, so using it in turmoil tests is either impossible or requires temporary directories and real disk I/O, which breaks determinism and slows tests.

Describe the solution you'd like
Add an optional turmoil feature that enables an in-memory or virtual filesystem backend (or a storage abstraction) so fjall can run under turmoil without touching the real filesystem. Ideally this would expose a config/trait to supply a FileSystem implementation, with a default std::fs backend and a turmoil-compatible backend.

Describe alternatives you've considered

• Using temp dirs on disk and running tests without turmoil (works but loses determinism and increases runtime).
• Wrapping fjall behind a separate mock layer in my app (more maintenance and still needs fjall internals to be mockable).
• Forking fjall to add an in-memory backend (undesirable to maintain).

Additional context
This would let projects that already use fjall (e.g., for mempool/DA storage) keep their test topology in turmoil while preserving deterministic behavior and avoiding filesystem side effects. If it helps, I can provide a minimal turmoil test that currently fails due to std::fs usage. I can do a PR

[marvin-j97]

See fjall-rs/lsm-tree#42

[hhalex]

Thanks for the link

[hhalex]

Same vibe, in addition to be able to plug a deterministic backend for file system, I am wondering how to extract the same kind of trait for the threadpool, to plug the monothreaded deterministic runtime of turmoil. This way i think i can fully simulate deterministically the whole thing, with fjall/lsm logic.