Return Error on Conflicting Credential Configuration

[tustvold]

Is your feature request related to a problem or challenge? Please describe what you are trying to do.

Comment from @alamb on https://github.com/apache/arrow-rs/pull/4235/files#r1196996290 suggested erroring if an object_store is constructed with multiple conflicting credentials. The current behaviour of not returning an error is consistent with the behaviour of tools like AWS SDK, but may not be desirable in all cases. Creating an issue to solicit thoughts.

Describe the solution you'd like

I'm honestly not sure, but I think we should probably either do nothing or return an error.

Describe alternatives you've considered

Additional context

[roeap]

I played around a little bit with how robust config handling might look like. Guessing the users intent from the passed configuration remains challenging, but I did come up with a rough draft of something that "might" eventually work.

The main idea is to provide a priority of credentials and the required configuration keys to construct a specific credential. Then so far doing several passes through the priority list.

• If the passed options contain a full credential we use that one.
• If the passed options contain some config for a credential, and we can augment the rest from the environment, we choose that.
• If we can parse a full credential from then env, we choose it.
• Else we fall back to config free credentials (i.e. metadata endpoints)

I was also thinking about having some notions of "tells" - e.g. for azure if a client secret is provided, we assume the user intents to use client secret auth, and error if we cannot find client and authority id ...

As mentioned, this is so far just a rough draft, but if you think this might lead somewhere I'd be happy to move the PR over here...

[alamb]

Another case that erroring might be preferable could be something like trying to configure your tool for a development environment by passing development credentials, but doing so in a shell or something that had production credentials as well.

In this case as as user I would definitely want an error rather than accidentally accessing the production systme

[roeap]

The way to go is maybe to keep the augmentation logic as a separate step, and not make it part of the builders itself. In test scenarios One would create a specific store instance via the builder, and may choose the have a config helper that augments from the env as a pre-processing step for the config before it gets passed into the builder.

Obviously that only works for the config API. Erroring in an ambiguous case - especially in the builder - seems very reasonable to me.