Provide health for an AbstractRoutingDataSource's resolved targets

[onobc]

Fixes gh-22824

[onobc]

I broke out of the CHCC hierarchy as this stretched that contract a bit too much. We need the createIndicator to return HealthContributor rather than AbstractHealthIndicator to allow for the case where one of the datasource beans is actual the AbstractRoutingDataSource which in turn is composite contributor.

[onobc]

We could have simply returned this CompositeHealthContributor.fromMap(routedDataSources, indicatorFunction) from here and not created a 1st class type for it. However, having the RoutingDataSourceHealthIndicator is helpful for testing as well as for future extensions to the indicator when/if needed.

[onobc]

@wilkinsona not sure if this is what you had in mind - let me know where we need to adjust. I have a couple of points/questions/caveats to discuss as well.

Relies on metadataprovider

As it is written, it relies on the available metadata providers to generate the validation query. Will it ever be the case that one of the routed datasources is not of the types we know about? Is that even possible?

I have since figured out this is not an issue as described here

By default, Spring Boot provides metadata for all supported data sources; you can add additional DataSourcePoolMetadataProvider beans if your favorite data source isn’t supported out of the box. See DataSourcePoolMetadataProvidersConfiguration for examples.

Duplicate indicators

If a routed datasource is also a registered @Bean DataSource then it will have a regular DataSourceIndicator created as well as be represented in the RoutingDataSourceHealthIndicator. The IsolationLevelDataSourceRouter seems like an example where the routed datasources are most likely already registered DataSource beans.

• Option 1 - do nothing
• Option 2 - add boolean property to "deduplicate" (ignore the routing datasource when its already represented)

One edge case on option 2 is when one of the routed datasources is already covered but another is not. Would we ignore only the covered target datasource in the routing health indicator? That would be strange.

I am inclined to go w/ option 1. I am curious to hear others thoughts as well.

[wilkinsona]

This looks great. Thank you, @Bono007.

I am inclined to go w/ option 1. I am curious to hear others thoughts as well.

Agreed. I think this is the better option.

Having the RoutingDataSourceHealthIndicator is helpful for testing as well as for future extensions to the indicator when/if needed

Agreed again. When looking at the main code I was tempted to get rid of it, but having looked at the tests I think it's useful to have the distinction. It's also a package-private implementation detail so we can refine in the future as needed without worrying about backwards compatibility.