Add S3 path style access support to exchange spooling

[linzebing]

Description

As title

Non-technical explanation

As title

Release notes

() This is not user-visible or docs only and no release notes are required.
( ) Release notes are required, please propose a release note for me.
(x Release notes are required, with the following suggested text:

# Section
* Add S3 path style access support to exchange spooling

[losipiuk]

@linzebing please update PR desc to include release notes text.

[colebow]

If we're adding a new configuration property, we need to make sure it gets documented. I'll get up a PR before release, but please try to include docs with the initial PR.

cc @losipiuk

[linzebing]

@colebow : I want to get some clarification on this. Do we document all configs, or only the important configs that users might need to adjust? Asking because I see a lot of configs not documented, and I think for this particular config, most people should use the default value.

[colebow]

There are a few reasons why a thing may be undocumented:

1. We messed up and it should've been documented (this is common - especially for older features that landed before we began making a push for better documentation).
2. It's experimental and it's going to be documented once it's better-tested and ready for wide use.
3. We're worried that documenting it will give users the bright idea to fiddle with something that they really shouldn't.

Not-so-great reasons to skip docs on something:

• Most people will use the default.
• It's a niche setting / not very important.

So basically, we only shouldn't document something when we're worried that telling our users about it is going to run the risk of causing problems. If the only consequence of documenting it is that it takes up a little extra space, we should put it in the docs.