Shut down embedded database when cleaner fails

[junhyeong9812]

Overview

EmbeddedDatabaseFactoryBean#destroy() runs the configured database cleaner and then shuts the embedded database down. If the cleaner throws, the shutdown is skipped and the in-memory database stays alive for the rest of the JVM. This PR makes sure the database is shut down even if the cleaner fails, while still propagating the cleaner exception.

Problem

The cleaner is typically configured through <jdbc:script execution="DESTROY"/> in <jdbc:embedded-database>. ResourceDatabasePopulator fails on the first error by default (continueOnError and ignoreFailedDrops are false), so a DESTROY script that drops a table that no longer exists, or a script that cannot be read, makes destroy() throw before reaching shutdownDatabase():

public void destroy() {
	DatabasePopulator cleaner = this.databaseCleaner;
	if (cleaner != null && getDataSource() != null) {
		DatabasePopulatorUtils.execute(cleaner, getDataSource());  // throws
	}
	shutdownDatabase();  // skipped
}

DisposableBeanAdapter only logs the exception, so the context closes normally. The in-memory database is not dropped though: the default HSQL database lives until SHUTDOWN is executed, and H2 databases are created with DB_CLOSE_DELAY=-1. Since the database name defaults to testdb, a subsequent context in the same JVM connects to the stale database and sees the previous schema and data, e.g. its own init script fails with "table already exists".

EmbeddedDatabaseFactory#initDatabase() already handles the equivalent case on startup by shutting the database down when the populator fails.

Fix

destroy() now calls shutdownDatabase() in a finally block. The cleaner exception is not caught, so it still propagates to the container as before, and the behavior is unchanged when the cleaner succeeds.

A new test configures a cleaner that drops a missing table, verifies that destroy() throws ScriptStatementFailedException, and then opens a new database with the same name and asserts that the table created by the populator is gone. It fails before the change and passes after it. The full spring-jdbc test suite passes.