Add support for starting a context that has been pre-processed

[snicoll]

The counterpart of #28065 is that we need a way to start an ApplicationContext that has been pre-processed. Part of the refresh phase for such a context already ran, and therefore should not be invoked again.

Removing a low-level infrastructure, such as a BeanDefinitionRegistryProcessor implementation registered as a @Bean can be dangerous as said bean may implement extra interfaces (bean instance post-processing) that should actually run.

Starting a context this way should also provide the information that it runs in "AOT optimized mode" so that components can decide for themselves if they need to do something or rely on the AOT optimization.

[snicoll]

A brainstorming with @wilkinsona helped make progress on this one. We could call the exact same callbacks (i.e. refresh rather an specific method) together with a "run level" that would indicate in which mode we're running:

• Regular (current runtime with no optimizations)
• Pre-processing optiomization (Add support for refreshing an ApplicationContext for AOT processing #28065)
• Runtime with pre-processing optimization (this issue)

Having such a high-level concept could be reused by Spring Boot when it needs to initializes components prior to the BeanFactory or the context itself.

[snicoll]

Discussed this proposal with @jhoeller and one important point is that the component in charge of the refresh should be the one opting-in for a certain behavior (rather than a flag that could be set externally by anything). A new refresh(Mode mode) could achieve that where the existing refresh() method calls it with the "regular" mode.

We've also discussed the possibility to introduce a ModeAware interface that would let components declare they're interested in which mode the context is being refreshed.

[snicoll]

We've decided to revisit this at an individual component level instead, leaving a global mode up to Spring Boot (see spring-projects/spring-boot#30559)