[transfermanager] Allow downloading directories that contain filenames with double dots

[PolovinaD]

Summary

Fix overly strict path traversal check in DownloadDirectory.

Problem

The current implementation uses:
strings.Contains(relPath, "..")

This incorrectly rejects valid filenames such as:

• file..txt

Solution

Replace with:
!filepath.IsLocal(relPath)

This:

• still prevents traversal (../)
• allows valid filenames containing '..'

Test

Updated TestDownloadDirectory to verify files with '..' in their names are allowed.
All unit tests pass.

[PolovinaD]

Just following up on this PR.

I've been using this change in production via the forked module and it has worked well so far. The workaround is manageable, but I'd like to simplify future SDK upgrades by returning to the upstream module.

This also resolves an upload/download asymmetry where object keys containing .. can be uploaded but can't be downloaded.

Happy to make any changes or add more tests if needed.

[wty-Bryant]

it's better to add other 2 cases combining path escaping :

"object key with double dots in name and path": {
			destination: "double-dots-in-name-and-path",
			objectsLists: [][]s3types.Object{
				{
					{
						Key: aws.String("foo/bar/../baz..zoo"),
					},
					{
						Key: aws.String("a..b"),
					},
				},
			},
			expectTokens:            []string{""},
			expectKeys:              []string{"foo/bar/../baz..zoo", "a..b"},
			expectFiles:             []string{"foo/baz..zoo", "a..b"},
			expectObjectsDownloaded: 2,
			listenerValidationFn: func(t *testing.T, l *mockDirectoryListener, in, out any, err error) {
				l.expectStart(t, in)
				l.expectComplete(t, in, out, 2)
			},
		},
"object key with double dots in name and path escaping": {
		destination: "double-dots-in-name-and-path-escaping",
			objectsLists: [][]s3types.Object{
				{
					{
						Key: aws.String("foo/../../baz..zoo"),
					},
					{
						Key: aws.String("a..b"),
					},
				},
			},
			expectErr: "outside of destination",
			listenerValidationFn: func(t *testing.T, l *mockDirectoryListener, in, out any, err error) {
				// only validate failure listener since start listener
				// might never be triggerred if the error response is returned first
				l.expectFailed(t, in, err)
			},
		},

[PolovinaD]

Thanks, that makes sense. I thought it was (partially) covered in error when path resolved from objects key out of destination scope above, but this is definitely more thorough. I updated it