Build: Bump software.amazon.awssdk:bom from 2.41.5 to 2.41.10

[dependabot]

Bumps software.amazon.awssdk:bom from 2.41.5 to 2.41.10.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[steveloughran]

anyone did a test run before this or does everyone trust aws sdk updates? For the s3a connector we've generally allocated 1 month per update because of its brittleness, especially with failure handling and third party storage.

[huaxingao]

We currently rely on CI for these bumps; no dedicated S3A test run was done for this change. Agree S3A can be brittle. We can probably add an S3A smoke/integration check for AWS SDK updates.

[steveloughran]

I'm less worried about S3A than S3FileIO & third parties; remember how they broke third-party last year -and iceberg shipped with a broken release #12649.

The AWS SDK team do not test their SDK against third party stores. This has been publicly stated.

It's why the S3A SDK update policy requires that third party testing, with google cloud the easiest for most people, especially as it lacks some features (no bulk delete; list api is v1).

https://github.com/steveloughran/engineering-proposals/blob/trunk/qualifying-an-SDK-upgrade.md

Last update (apache/hadoop#8059)
we found two sdk regressions 6518 and 6459, the latter a performance regression with S3 express. So it's less "s3a is brittle" and more "test suite is brutal enough it'll find bugs in the SDK and even differences between aws stores"

[huaxingao]

Thanks @steveloughran — this is helpful context.
We should follow up by documenting an Iceberg-side SDK upgrade qualification checklist and wiring integration tests for iceberg-aws/S3FileIO. I think we should open an issue to track this.