aws: fix dual-stack endpoint disable not being honored

[seanmacisaac]

The previous implementation called aws.GetUseDualStackEndpoint() without arguments, which always returns (Unset, false) since it requires endpoint resolver options to inspect. This meant AWS_USE_DUALSTACK_ENDPOINT=false was not being honored, causing failures in regions without dual-stack endpoints (e.g., me-central-1).

The fix uses config.NewEnvConfig().GetUseDualStackEndpoint() to properly read the environment variable. When explicitly set to "false", dual-stack is now disabled. When "true" or unset, behavior is unchanged (dual-stack enabled for backward compatibility).

This is a backward-compatible fix:

• AWS_USE_DUALSTACK_ENDPOINT=true -> dual-stack enabled (unchanged)
• AWS_USE_DUALSTACK_ENDPOINT unset -> dual-stack enabled (unchanged)
• AWS_USE_DUALSTACK_ENDPOINT=false -> dual-stack disabled (THE FIX)

Also adds:

• Table-driven tests for both static credentials and default credential chain (IAM role) paths covering all dual-stack configurations
• A test CLI tool (cmd/test-aws-discover) for manual verification in AWS, since unit tests cannot fully verify endpoint behavior without real AWS API calls

Fixes #293

PCI review checklist

• I have documented a clear reason for, and description of, the change I am making.

• If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.

• If applicable, I've documented the impact of any changes to security controls.

  Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.

[hashicorp-cla-app]

All committers have signed the CLA.

[hashicorp-cla-app]

Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement

Learn more about why HashiCorp requires a CLA and what the CLA includes

_{Have you signed the CLA already but the status is still pending? Recheck it.}

[seanmacisaac]

FYI, when authoring this I chose to leave the existing default behavior. That was a breaking change with no work around when dual stack was first introduced since not all AWS regions have dual stack endpoints, but I'm sure that change was motivated by some people needing the dual stack endpoints to be used so rather than introduce yet another breaking change this just makes it possible (via config) to not use dual stack endpoints. That still means people running services in regions that don't support this will need to adjust their config to explicitly request non-dual-stack endpoints but at least there will be a way to do that, but that should probably be noted in all of the services (vault, consul, nomad, etc) that use this.

[ksandrmatveyev]

Hi @seanmacisaac , was it stuck on CLA submission or so?

[seanmacisaac]

@ksandrmatveyev not sure. I see this, not sure why one says it is clear and one not. In the checks section it is clear, looks like it just needs someone at Hashicorp to review. I know a lot of OSS maintainers are getting swamped with AI generated PRs that aren't very good.