hints for developers still using llfuse

i had a look at pyfuse3 and these are the results:

• the API you have to use is quite similar, so a lot of code can be reused (note that pyfuse3 started as a fork of llfuse)
• the main difference is that Operations methods are expected to be async def now
• there is also a minor difference in readdir method: not yielding results, but calling a pyfuse3 function with a token

availability and issues of llfuse and pyfuse3

• pyfuse3 has issues on freebsd and does not yet work on macOS.
• pyfuse3 is also not available on older dists that do not have fuse3 yet.
• pyfuse3 is not developed any more, but gets maintenance.
• llfuse is widely available, but not developed any more, but gets maintenance. but it works on linux, freebsd, macOS.
• due to these circumstances and as the api of both libraries is similar, one wants to support both with the least effort possible for now. later, when everybody has pyfuse3, llfuse can be dropped.

coexistence of usage of llfuse and pyfuse3 api in same codebase

• import either pyfuse3 or llfuse as fuse_impl (use an env var to enable the user to choose)
• have a decorator that cares for async def (or not), depending on which fuse_impl is used
• have 2 readdir method implementations depending on fuse_impl
• have a slightly different mount code (the new async way for pyfuse3 will use trio to run the code)
• most of your code can be shared between both!

Example of a port, with coexistence of llfuse and pyfuse3: borgbackup/borg#5430

Note: In that port, I used llfuse (not fuse_impl) as the name to represent either the pyfuse3 or the llfuse module.