Add support in the TCF to use pre-processed AOT contexts

[snicoll]

Overview

Once we've done #28204, we need to be able to configure the TCF so that it uses our optimized context rather than doing all the parsing again. Given that our input is the test class, it would be interesting to see if we can shortcut most of the processing and go straight to starting (or reusing) the context.

Related Issues

• Add support for starting a context that has been pre-processed #28066
• Add support in the TCF to use pre-processed AOT contexts #28205
• Introduce TestClassScanner to locate Spring test classes for AOT processing #28824
• Introduce command-line application for triggering AOT test context processing #28825

[snicoll]

Brainstorming with @jhoeller we believe that AotDetector should be used the same way as it is used when starting an application. When an app determines if it has to use AOT, it uses the detector and load a generated class by convention and use it to initialize the context. If such a class is not present, an exception is thrown.

For the TCF, it could use the AotDetector, check a generated class based on the current test class name and then do whatever. An example of such arrangement could be the following:

/**
 * Bootstrap for {@link MyTest}. Generated code, do not edit
 */
public class MyTest__TestContextInitializer {
	
	public static SmartContextLoader loadContext() {
		return new AotContextLoader(...);
	}
}

The class could also implement an interface or whatever. If multiple test classes share the same context, then the generated code for those test classes would delegate to a common generated class.

Such arrangement makes sure that the check is consistent (and 100% transparent when running tests in a native image).