Add support for AWS Advanced JDBC Wrapper

[vpavic]

This commit adds entry for AWS Advanced JDBC Wrapper to DatabaseDriver enum.

See gh-31995

[vpavic]

I've used List#of as it seems to be the simplest option, but note that implementations of #getUrlPrefixes in this enum are quite inconsistent - there are usages of Arrays#asList and Collections#singleton.

Perhaps this could be aligned in a separate issue to use List#of consistently (first-timers-only candidate?).

[wilkinsona]

Thanks, @vpavic. In isolation, I wonder how useful this will be. Looking at how DatabaseDriver is used, being able to detect AWS's wrapper may not be enough in some cases. Take Flyway's auto-configuration for example. As you may remember as I think you contributed it, it uses DatabaseDriver to figure out which vendor-specific migrations to use. In that situation, I think we'd need to detect the driver that's being wrapped rather than the wrapper. I think the same applies to the basic script-based initialization and the like as well.

[vpavic]

Thanks for the feedback.

Motivation here is to simplify usage of AWS Advanced JDBC Wrapper by not having to specify spring.datasource.driver-class-name property. Depending on the environment (and the exact database used), sometimes we need to use plain PostgreSQL JDBC driver and other times AWS wrapper - it would be very useful to do that switch only by changing a single configuration property.

I understand your concerns, and have refreshed my memory a bit on support for vendor-specific Flyway migrations (yes, I contributed that quite some while ago 🙂) and I believe your comment aims at this usage of DatabaseDriver:

spring-boot/spring-boot-project/spring-boot-autoconfigure/src/main/java/org/springframework/boot/autoconfigure/flyway/FlywayAutoConfiguration.java

Lines 391 to 392 in 269c761

	String url = JdbcUtils.extractDatabaseMetaData(this.dataSource, DatabaseMetaData::getURL);
	return DatabaseDriver.fromJdbcUrl(url);

This indeed doesn't play nice with wrapper drivers but such use cases could be updated to rely on database product name instead. I can contribute that if you agree with that direction.

I can see that such approach is already used in PlatformPlaceholderDatabaseDriverResolver:

spring-boot/spring-boot-project/spring-boot/src/main/java/org/springframework/boot/jdbc/init/PlatformPlaceholderDatabaseDriverResolver.java

Lines 139 to 141 in 269c761

	String productName = JdbcUtils.commonDatabaseName(
	JdbcUtils.extractDatabaseMetaData(dataSource, DatabaseMetaData::getDatabaseProductName));
	return DatabaseDriver.fromProductName(productName);

In any case, I think these concerns are not new since Testcontainers JDBC driver also is of similar nature as it wraps the underlying JDBC driver and requires inserting its prefix into JDBC URL.