Exit with non-zero status code if allow_other is used but not enabled in fuse config

[vibhansa-msft]

Fix for #1081

[cvvz]

Please take a look at #1088. I think it should be the right way to solve this kind of problem, instead of handling the -o allow_other option alone.

[vibhansa-msft]

Please take a look at #1088. I think it should be the right way to solve this kind of problem, instead of handling the -o allow_other option alone.

That other PR will not solve this issue as post those changes blobfuse binary will exit with non zero status code but still does not give any hint on what went wrong.

[cvvz]

Since this PR has been merged and I'm not the expert of blobfuse V2, so I'm not going to oppose to this pr.

However, I have to say that with #1088, we can sure get the error code and error message, which is directly returned from libfuse.

The other concern about this PR is that: if we decide to upgrade libfuse someday and some behavior changed, or if there are some differences from fuse v2 and fuse v3, we may still encounter some problem and have to add more similar changes in blobfuse2 validation logic.

[andyzhangx]

@vibhansa-msft pls hold on releasing any new blobfuse2 version, we are setting up a daily e2e test validation on blobfuse2 main branch, to make sure there is no regression after integration with blob csi driver.

[cvvz]

@vibhansa-msft Can you test with #1088 again to see if it can solve this issue? I've tested and it can provide error message from libfuse. Please rethink about this PR. Considering the risk I just raised, I'd prefer we solve this problem by #1088, rather than this PR. Thanks