Fixes issue #3479 where S3ForcePathStyle is unable to be read from a config file

[peterrsongg]

Description

A user can set ForcePathStyle on the AmazonS3Config object but it doesn't get read from the config file which makes it difficult to set when using something like the AWSSDK.Extensions.NetCoreSetup library, since that creates the client under the hood. This just adds the ability to read this value from the config file.

Motivation and Context

Fixes issue #3479

Testing

Dry run in v3 passes
Added unit tests which pass.

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist

• My code follows the code style of this project
• My change requires a change to the documentation
• I have updated the documentation accordingly
• I have read the README document
• I have added tests to cover my changes
• All new and existing tests passed

License

• I confirm that this pull request can be released under the Apache 2 license

[dscpinheiro]

For reference, it doesn't look like other SDKs are reading (or expecting?) a s3_force_path_style property in the config file. The closest one I found was the CLI, which has a S3 specific section: https://docs.aws.amazon.com/cli/v1/userguide/cli-configure-files.html#cli-configure-files-s3

[profile development]
s3 =
  max_concurrent_requests = 20
  max_queue_size = 10000
  multipart_threshold = 64MB
  multipart_chunksize = 16MB
  max_bandwidth = 50MB/s
  use_accelerate_endpoint = true
  addressing_style = path

Where addressing_style is:

Specifies which addressing style to use. This controls whether the bucket name is in the hostname or is part of the URL. Valid values are: path, virtual, and auto. The default value is auto.

[peterrsongg]

doesn't look like other SDKs are reading (or expecting?)

yeah talking to others in the org, it looks like this isn't something we should add unless it is consistent across SDKs