Avoid calling chmod in cpDirRecursive

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
https://github.com/actions/toolkit/blob/ef77c9d60bdb03700d7758b0d04b88446e72a896/packages/io/src/io.ts#L294

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

Start at packages/io/src/io.ts around line 294, where cpDirRecursive performs chmod, and trace how the copy handles permissions. Reproduce or inspect behavior on a filesystem that rejects permission changes, then verify that copying still succeeds without turning an unsupported chmod into a failure.