Conditionally set default crt target_throughput

[hssyoo]

Conditionally sets a default target_throughput value for the CRT client:

• (Unchanged) If host is optimized, use value from get_recommended_throughput_target_gbps().
• If newly eligible host auto-resolving to CRT and get_recommended_throughput_target_gbps() returns None, set it to 4gbps.
  • 4gbps maps to a max 256MiB memory pool. Since we don't have host details, we use the smallest supported pool size.
• If CRT is explicitly configured, use the maximum value of (get_recommended_throughput_target_gbps(), 10gbps).
  • 10gbps is CRT's default when there's no recommended throughput. We don't want to lower throughput for instances that now return a recommended throughput <10gbps.

There's an edge case where we need to fall back to the classic transfer manager if the configured multipart_chunksize > 128MiB and it's a newly eligible host auto-resolving to CRT and there's no recommended throughput for the host. CRT client creation has a guard that ensures part_size < memory_limit / 2. Since under these conditions we set 4gbps throughput with a 256MiB memory limit, a configured part size of 128MiB will always fail. Instead of dynamically adjusting the memory limit based on part size (potentially regressing on OOM issues), we just fall back to Python.

[ashovlin]

Should this consider if the user set an explicit target bandwidth too?

Say I'm running locally, so there isn't a CRT tuning available. I set a > 128MiB chunk size, but also an explicit >10Gbps target bandwidth, wouldn't CRT still be acceptable then?

[hssyoo]

Fixed via d5d74f0

Instead of attempting to hardcode the max part size and guess whether the configurations/hardware are valid, it just attempts to create the CRT client and catches the part size error and falls back to classic.