[BREAKING] feat: Support passthrough API

[khanhtranngoccva]

The fuser crate supports passthroughs and it is possible that a user wants to forward most or all operations directly to the kernel instead of handling FUSE manually. The open and opendir method now exposes an extra object OpenHelper that allows users to allocate a backing ID by calling open_backing, and the ID should be returned by these methods. The user also no longer needs to manually manipulate FUSEOpenResponseFlags.

[khanhtranngoccva]

Note: this PR is bleeding edge and uses a forked version of fuser to demonstrate the feature, do not merge it yet.

[Alogani]

Hi khanhtranngoccva,

As for my other comments, having code mixed from different PRs doesn't help me understand your intent and changes (even i you mentioned this PR is not to be merged yet).

This is an interesting idea and i understand the attraction of using passthrough of fuse. However i am not familiar with it, can't using passthrough API allow to not use at all InodeMapper API ? It would be interesing to allow a full delegation of inodes handling to the final user (for example, the user would provide the inodes of an existing unix filesystem). However providing this ability would introduce a lot of breaking changes in how it is handled right now (and i haven't the impression this is how you decided to handle it). If that is the case, it would be better to allow the final user to provide its own InodeResolver through dependency injection.

But, even if it seems a nice feature, is there really a use case for such a niche feature? If a user want to go so low level, it would be better to use directly fuser crate than my "high level" easy_fuser.

[khanhtranngoccva]

This PR is superseded by #73.