Major refactor to eliminate reply callbacks, revised

[rarensu]

Summary:

• The long-anticipated major refactor to eliminate the unwanted reply callback paradigm inherited from libfuse.
• See Changelog.md for more details.
• This PR is the sequel to PR Major refactor to eliminate reply callbacks #345, forked because @cberner requested smaller commits with more focused changes.
• Thanks to @allisonkarlitskaya for useful suggestions.

Goals:

• Avoid functional changes and preserve existing features when possible.
• Eliminate callbacks to prepare for future development of async features.
• Support a variety of data ownership models to encourage a zero-copy solution.
• Fully integrate the notification and passthrough features.
• Better documentation. More illustrative examples.
• Attention to ergonomics, readability, maintainability, and style (cargo clippy).
• Continue to support MacOS.
• Continue to support the synchronous, single-threaded execution model.

Status:

• Tested on Redhat 9, Ubuntu 24, and MacOS 10.15
• All features compile; many combinations of feature flags tested.
• All new and existing unit tests and integration tests pass.
• All examples (except ioctl) are known to function correctly.

Next:

• Example ioctl_client to assist with testing the ioctl example.
• First draft of async/await features.

[rarensu]

Since @cberner said he doesn't have a lot of time to look at pull requests, I asked Gemini 2.5 Pro to review it. Here is the prompt I (foolishly) went with:

You are a senior software engineer specializing in low-level library development for the Linux operating system family. Your task is to review a Git pull request #347. Your priority is to protect existing users of the cberner/fuser repository, who depend on it to develop userspace filesystem applications in Rust. The Author, Richard Lawrence, is a newcomer to the community and therefore he has not yet earned any trust. The code in the pull request is assumed to be incomprehensible, inefficient, and/or insecure, until proven otherwise.

Have you ever seen an AI rip someone to shreds? I've now got about 14,000 words of harsh negative feedback to brutalize myself with whenever I feel the need to cry myself to sleep. It literally called my Container construct a footgun. (it preferred @allisonkarlitskaya's Cow idea). For your entertainment, I also asked it produce the podcast version.
https://notebooklm.google.com/notebook/f9b377ef-36f8-4b4d-8998-ae901c96868a/audio

TLDR, I should probably just withdraw this PR before I embarrass myself even further.

[cberner]

That notebook isn't accessible, but ya AIs are known to be harsh when you ask them to be.

In its current state, I don't think we'll be able to merge this PR. If you decide to continue pursuing this, I think the approach to take is the one I outlined in this comment: add a new trait, such as AsyncFilesystem with the refactored API, then add an adapter like:

struct<T: AsyncFilesystem> AsyncToLegacyAdapter<T> {
...
}

impl<T> Filesystem for AsyncToLegacyAdapter<T> {
// implementation of Fileystem which calls the AsyncFilesystem
// this doesn't need to be particularly efficient, as long as it is correct.
}

That way we can experiment with the new API, and people in the community can try it out and give feedback, before refactoring the whole codebase and removing the old interface