Fix EC2 DescribeInstances query use locale-dependent formatting

[Fred1155]

Motivation and Context

User reported the issue #5968. Currently we are render the filters using locale-dependent numerals, UTF-8-encoded. For example, for instance running in the ne (Nepalese) local the query uses Filter.%E0%A5%A7.Name rather than Filter.1.Name, where %E0%A5%A7 is the UTF-8 encoding for U+0967 DEVANAGARI DIGIT ONE which is the rendering for the integer 1 in this locale. The expected behavior is in all locales, we should render the filters using ASCII digits 0 to 9 only.

Modifications

The current ListQueryMarshaller code uses String.format("%s.%d", path, i + 1) which is locale-dependent. When formatting the %d (decimal integer), Java uses the system's default locale to determine how to display numbers.
Locale.ROOT is Java's locale-neutral locale. By adding that to String.format, it will always produce ASCII digits regardless of system locale. This issue only appear for Java version 9 and above.

Testing

Added unit test for ListQueryMarshaller class and also did a local integration test using the self-repro code provided in the original issue.

Screenshots (if appropriate)

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)

Checklist

• I have read the CONTRIBUTING document
• Local run of mvn install succeeds
• My code follows the code style of this project
• My change requires a change to the Javadoc documentation
• I have updated the Javadoc documentation accordingly
• I have added tests to cover my changes
• All new and existing tests passed
• I have added a changelog entry. Adding a new entry must be accomplished by running the scripts/new-change script and following the instructions. Commit the new file created by the script in .changes/next-release with your changes.
• My change is to implement 1.11 parity feature and I have updated LaunchChangelog

License

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

[alextwoods]

Overall change looks good - Are there other areas where we are formatting URL components that we should make a similar fix for?

[millems]

Would it be simpler to just do path + "." + (i+1)?

String.format is relatively slow compared to building the string manually, anyway.

[Fred1155]

Thanks for the suggestion! will check other path resolvers that uses String.format("%d"). Just did a test and using concatenation also fixes the locale problem.

[Fred1155]

Overall change looks good - Are there other areas where we are formatting URL components that we should make a similar fix for?

Good suggestion! I think technically this fix could be applied to all path resolver that uses String.format("%d")?

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[github-actions]

This pull request has been closed and the conversation has been locked. Comments on closed PRs are hard for our team to see. If you need more assistance, please open a new issue that references this one.