Add support for FUSE3 on Linux

[jfantinhardesty]

This pr adds support for FUSE3 on Linux and and makes a slight modification to the FileSystemBase interface to allow building for both FUSE2 and FUSE3. FUSE2 support is maintained and the default build option. To build with FUSE3 support you must use the fuse3 build tag which will then link to fuse3.

Additionally, some of the command line options changed in FUSE3 so direct_io and use_ino can no longer be set as command line options when starting a mount. These must be set in fuse_config so there are some additional functions introduced to set these options.

This also updates the CI/CD to test for FUSE2 and FUSE3 on Linux. It also only checsk the ability to build on MacOS since the old image is no longer available as a GitHub action and requires a restart to test the filesystem in GitHub actions.

This resolves #50.

[billziss-gh]

Great work with this PR. I would love to see a version of this PR incorporated into cgofuse.

Unfortunately the PR as it currently stands makes cgofuse backwards incompatible with existing file systems. It is a goal of this project to maintain backwards compatibility. There are far too many file systems using cgofuse, both open source and closed source to do otherwise.

The main reason for the incompatibility is the change in the Rename, Chmod, Chown, Utimens methods of FileSystemInterface. I would like the FileSystemInterface to remain as is and we could introduce the new method signatures as:

• Either individual small interfaces as it is currently done for (e.g.) FileSystemOpenEx. For example, FileSystemRename3 for the FUSE3 version of Rename.

• Or a whole new FileSystemInterface3 with the new methods.

There may be other options to consider and I am happy to discuss them as long as we maintain backwards incompatibility.

CC'ing @ncw who is (via rclone) one of the biggest open source cgofuse clients.

[ncw]

Very nice. Rclone users have been requesting this 😄

I agree with Bill this shouldn't change the interfaces and break backwards compatibility though.

Can we make the old interfaces work and do something sensible with fuse3. I guess it might require multiple calls to emulate something where a fh is passed in.

Another alternative would be to only provide the new interface when the fuse3 tag is supplied. This would complicate the implementation though.

Another alternative would be to declare a v2 for cgofuse. That would be the least extra code and would give a chance to clean up the Ex interfaces if we wanted.

I thought the whole v2 thing was poorly thought through when I first read about it, but having been through it with some popular packages (eg ncw/swift ) it isn't too scary and works well. We would make a v1 branch which could receive minimal or no support (no support was what I chose) and then master becomes v2.