Avoid calling chmod in cpDirRecursive

[nikolaik]

Describe the enhancement

When running this code on a self hosted runner, called by google-github-actions/setup-gcloud and trying to back RUNNER_TOOL_CACHE with a S3 bucket, it fails with EPERM: operation not permitted, chmod '/opt/hostedtoolcache/somedir. Running chmod on a filesystem that does not support changing permissions will always throw EPERM errors. Is it necessary to copy over permissions explicitly instead of relying on default umask and/or file system defaults?

Could we catch possible EPERM exceptions when running chmod in this scenario?

Code Snippet

The relevant code

toolkit/packages/io/src/io.ts

Line 294 in ef77c9d

await ioUtil.chmod(destDir, (await ioUtil.stat(sourceDir)).mode)

Additional information

The cp command, -p is an option with the following described behaviour:

From the macOS man pages:

   -p    Cause cp to preserve the following attributes of each source file in the copy: modification time, access time, file flags, file mode, user
           ID, and group ID, as allowed by permissions.  Access Control Lists (ACLs) and Extended Attributes (EAs), including resource forks, will also
           be preserved.

           If the user ID and group ID cannot be preserved, no error message is displayed and the exit value is not altered.

           If the source file has its set-user-ID bit on and the user ID cannot be preserved, the set-user-ID bit is not preserved in the copy's
           permissions.  If the source file has its set-group-ID bit on and the group ID cannot be preserved, the set-group-ID bit is not preserved in
           the copy's permissions.  If the source file has both its set-user-ID and set-group-ID bits on, and either the user ID or group ID cannot be
           preserved, neither the set-user-ID nor set-group-ID bits are preserved in the copy's permissions.

The AWS S3 fuse driver which throws EPERM https://github.com/awslabs/mountpoint-s3-csi-driver