Run passing tests from pjdfstest

[gaul]

This downloads a tarball by hash instead of using a submodule.
References #1589.

[gaul]

Any ideas on what is the correct way to do this?

[ggtakec]

Setting pjdfstest as a submodule is a bit thoughtful.

I want the s3fs repository to be able to work independently.
I don't think I agree with mixing the pjdfstest build with the s3fs build.
The pjdfstest build is the environment required for the s3fs build(and test), and I think it's better to separate this part.

If you want to use pjdfstest in s3fs test, what about the following method?

• In github actions, git clone pjdfstest under the test directory(this can be done with ci.yml. You can prepare a helper script if necessary)
• And in the pjdfstest directory, do that build

How about performing this step only during CI?

Anyone can deploy it on localhost other than CI by preparing a dedicated helper script.
(Alternatively, you may prepare another repository(ex. s3fs-fuse/s3fs-pjdfstest, etc.) and dedicate it. But this is still an idea I just come up with, so it may be wrong.)

[ggtakec]

I came up with another one.
You may want to call the script as a PHONY target in the Makefile (.am) of the test directory.
(Clone and build pjdfstest in the script)

[ggtakec]

I made a example. (see proto_pjdfstest branch in my personal repo)
ggtakec/s3fs-fuse@master...proto_pjdfstest

I haven't implemented a "test" using pjdfstest yet...(because I don't know how you want to do it)
This way, pjdfstest can be made independent for now, which is in line with my wishes.

[gaul]

I reworked this to download the tarball which is cleaner.

[gaul]

This seems to show some real failure with rmdir and -o use_cache

[gaul]

This increases CI run-time by 50% so we should be careful if we want to merge this PR.

[gaul]

CI recently started failing with these kinds of errors:

2023-09-14T19:14:38.4260487Z cp(-p) expected times: mtime( 1694718792.836254751 == 1694718792.852005368 ), ctime( 1694718792.836254751 != 1694718792.848255678 ), atime( 1694718792.834613324 == 1694718792.834613324 )
2023-09-14T19:14:38.4260909Z test_mtime_file failed

2023-09-14T19:14:38.4362592Z cp with -p option expected updated ctime: 1000000000.000000000 != 1694718798.132663109 and same mtime: 1000000000.000000000 == 1000000000.000000000, atime: 1000000000.000000000 == 1694718798.133826699
2023-09-14T19:14:38.4363207Z test_update_time_cp_p failed

I don't think they are related to this PR.