feat: support for spring.config.import GCP Secret Manager

[JoeWang1127]

External resources from GCP Secret Manager can be imported to custom project by add the following line in the application.properties:
spring.config.import=sm://

This feature is implemented using Spring Boot’s Config Data API, more info can be found in here
fix #149

Users who want to use this feature should either exclude <artifactId>spring-cloud-starter-bootstrap</artifactId> from their dependency or to set spring.cloud.gcp.secretmanager.legacy=false

[elefeint]

Did not finish reviewing, sorry. But initial couple of comments.

[elefeint]

I've tested everything, and functionality is great -- everything works, even when both legacy and config.data ways work together. Having refresh work is also awesome.

I have a
I've been thinking about the different usage scenarios for Secret Manager, and realized I was missing the one where users don't need property discovery, but still want things like SecretManagerTemplate autoconfigured.

1. Users still on the "old" system of using legacy bootstrap phase. This should be the default, and they should both get SecretManagerTemplate autoconfigured, and have "sm://property" type values resolved.

2. Users on the new system -- they would have "spring.config.import=sm://" in application.properties and "spring.cloud.gcp.secretmanager.legacy=false" in bootstrap.properities. They should get SecretManagerTemplate autoconfigured, and have "sm://property" type values resolved, just like in (1).

3. Users with ""spring.cloud.gcp.secretmanager.legacy=false" and no "spring.config.import=sm://" -- the end result here is that "sm://" properties do not get resolved at all, but these users still need SecretManagerTemplate to be autoconfigured. Currently, this is a completely contrived scenario because why would someone do that? But once we remove the legacy bootstrap option in the next major release, this will be a common default scenario.

To make sure we are covering these options, could you add an autoconfiguration test similar to SecretManagerBootstrapConfigurationTests where those 3 scenarios are tested?

To do so, you'll need to mock out the real SecretManagerClient. Take a look at SecretManagerBootstrapConfigurationTests.secretManagerClient() -- this works because the boostrap configuration has @ConditionalOnMissingBean. Since you are programmatically registering the client instead, this exact approach won't work, but I think the current implementation using context.getBootstrapContext().registerIfAbsent() will do something similar and avoid creating a real client if a mock one is already present in context. You'll have to test it.

[JoeWang1127]

I've tested everything, and functionality is great -- everything works, even when both legacy and config.data ways work together. Having refresh work is also awesome.

I have a I've been thinking about the different usage scenarios for Secret Manager, and realized I was missing the one where users don't need property discovery, but still want things like SecretManagerTemplate autoconfigured.

1. Users still on the "old" system of using legacy bootstrap phase. This should be the default, and they should both get SecretManagerTemplate autoconfigured, and have "sm://property" type values resolved.
2. Users on the new system -- they would have "spring.config.import=sm://" in application.properties and "spring.cloud.gcp.secretmanager.legacy=false" in bootstrap.properities. They should get SecretManagerTemplate autoconfigured, and have "sm://property" type values resolved, just like in (1).
3. Users with ""spring.cloud.gcp.secretmanager.legacy=false" and no "spring.config.import=sm://" -- the end result here is that "sm://" properties do not get resolved at all, but these users still need SecretManagerTemplate to be autoconfigured. Currently, this is a completely contrived scenario because why would someone do that? But once we remove the legacy bootstrap option in the next major release, this will be a common default scenario.

To make sure we are covering these options, could you add an autoconfiguration test similar to SecretManagerBootstrapConfigurationTests where those 3 scenarios are tested?

To do so, you'll need to mock out the real SecretManagerClient. Take a look at SecretManagerBootstrapConfigurationTests.secretManagerClient() -- this works because the boostrap configuration has @ConditionalOnMissingBean. Since you are programmatically registering the client instead, this exact approach won't work, but I think the current implementation using context.getBootstrapContext().registerIfAbsent() will do something similar and avoid creating a real client if a mock one is already present in context. You'll have to test it.

Unit tests on different scenarios are added.

[elefeint]

I've retested both scenarios manually, and they work great.
At this point, I only have minor nits.

Could you also add documentation in both secretmanager.adoc and secretmanager.md to instruct users how to enable the new, Config Data way?

[elefeint]

Tiny wording updates, and done!!!

Merge it in.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
2 Code Smells

84.0% Coverage
0.0% Duplication