fix(s3): transfers are now single-threaded

[raphkim]

Issue #, if available:
#1947

Description of changes:
Default behavior for transfer utility was to use thread pool size = # available processors. This allowed multipart upload to be executed in parallel for a minor performance boost. However, we found that this was causing certain upload part requests to be prioritized over others, which in turn timed out the requests that were not being prioritized.

To increase the stability of large file uploads, this PR aims to force single-threaded multipart uploads by default (parts will be uploaded serially).

Main task executor to be used for downloads and single-part uploads will still be multi-threaded so that small transfers are not blocked by large file uploads.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

[richardmcclellan]

Could we just change the default pool size to 1, defined here instead? That way, we won't break the override.

[raphkim]

Main task executor was left untouched intentionally so that one large file upload does not block other transfers completely. Otherwise, if a user wants to upload a 1GB file while downloading 3 small files (5KB each) from S3, then the downloads will not start until upload is completed.

[richardmcclellan]

Could we just change the default pool size to 1, defined here instead? That way, we won't break the override.

@raphkim and I chatted offline about this. Changing the default pool size to 1 would impact both the main executor, and the part executor. We do want to serialize the part executor tasks, because the performance benefit with large (5MB) payloads is minimal, at the expense of reliability. However, that's not true for small payloads, because there is performance benefit in parallelizing the initial latency for each request. For example, if downloading multiple small files, parallelizing will likely help performance. And, timeouts are much less likely, since each task finishes quickly, so reliability is not as big of an issue.

So, the change in this PR hard-codes the part executor pool size to 1, but still lets customers customize the size of the main executor thread pool (via setTransferThreadPoolSize(...))

[arunj-kp]

@raphkim I don't think it is a good idea to disable multithreading for multipart uploads. Multithreads give high performance boost while uploading files greater than 20MB for the users on high bandwidth network (like >100Mbps). So, we need to investigate and fix the reason for upload failure on multithreads rather than disabling it.
What is the behavior in the iOS SDK? does it support multithreading for multipart uploads?