Support multiple Spring application names for AWS Secrets Manager

[leekib]

Support multiple spring application names for AWS Secret Manager

Spring Cloud Config supports multiple application names in backends like Git and Vault, but this feature seems to be missing in AWS Secret Manager. This change enables AWS Secret Manager to handle comma-separated application names, aligning with these backends.

This implementation is similar to PR #1379, which added support for multiple applications in the Vault backend, and resolves the limitations discussed in issue #1356.

What’s Changed

• Enabled processing of comma-separated application names for AWS Secret Manager, allowing it to handle multiple applications like Git and Vault backends.

Why This Matters

• Teams migrating from Git or Vault to AWS Secret Manager can now use the same configuration structure.

Testing

• Added test cases for:
  • Non-existing profile and label.
  • Default profile with an existing label.
  • Existing profile with null label.

[ryanjbaxter]

Are there existing tests that verify that changing this logic doesn't break anything? I am nervous that we might be changing the order of certain property sources and breaking expectations.

[leekib]

This one appears to provide good coverage for the logic changes in AWS Secrets Manager, particularly regarding the ordering and inclusion of profiles.

It helps ensure that:

• Profiles specified as a comma-separated list (like "prod,east") are handled in the correct order.
• null profiles are properly included.
• The default profile is correctly added, and its position relative to other profiles (including null profiles) is maintained.

For label-related scenarios, testFindOneWithExistingApplicationAndDefaultProfileAndExistingLabelWhenMultipleLabelIsSet seems to cover the handling of multiple labels effectively.

Based on my review, these tests, along with testFindOneWithNullApplicationAndNonExistingProfileAndNullLabelWhenDefaultLabelIsSet and testFindOneWithExistingApplicationAndNonExistingProfileAndNoDefaultProfileForFooAndNullLabelWhenDefaultLabelIsSet, seem to cover the existing logic quite well.

[leekib]

I added a comprehensive test case to thoroughly ensure that the logic for retrieving secrets remains consistent with the previous implementation.

The test covers scenarios with multi-profiles and multi-labels, including default profiles and null profiles, verifying the exact order of secrets in all cases.

[ryanjbaxter]

The tests are great! Thank you!