Allow to provide a pre-computed scan PersistenceUnitManager

[snicoll]

DefaultPersistenceUnitManager is quite classpath-scanning centric. With AOT, we'd like to invoke the scanning of the classpath at build-time and generate a representation of the entities that should be contributed in the PersistenceUnit.

We have a similar problem in Spring Boot with other data stores that is being investigated in spring-projects/spring-boot#30523. The solution there is to have some sort of contract where one implementation is the scanning logic, and another that provides values straight away. I don't know if that would apply here.

The purpose of this issue is to investigate how we could swap this logic when AOT runs so that it uses an hard-coded list, while providing the list to 3rd parties that might need it at build time for further processing

[snicoll]

I've tried to extract a strategy interface in snicoll@60f7697. I don't have an alternative implementation for the AOT use case but it could be as simple as getting the entities and the mapped resources and provide that back.

It is a bit too magic though as the scope of what the initializer is not clearly specified. I have a feeling that the contract should be changed to produce something else. Maybe an intermediate object that contains the entities and mapped resources?

[snicoll]

brainstorming with @jhoeller, we're more aiming towards replacing the DefaultPersistenceUnitManager by an implementation that would know about the scanned entities and mapped resources.

[snicoll]

So the current plan is to allow AbstractEntityManagerFactoryBean to be "half-initialized" at build-time, preventing the actual EntityManagerFactory to be created. This lets us extract information for the PersistenceUnitInfo and the AOT contributions can be rewritten to use that rather than classpath scanning.

Also, Spring Data can then get the same bean as well, and get the same information to generate their metamodel.

[snicoll]

95b826b has some initial work for this. It loads the FB and sets the result of the scanning in the AOT-generated bean definition.

#28838 is now a prerequisite for this (in one form or another) as the DataSource is starting up at build-time as well.

[snicoll]

In the end we extracted the logic of scanning in a dedicated type, PersistenceManagedTypes. This is quite similar to the approach Spring Data took with its ManagedTypes abstraction. The change in public API is minimal and packagesToScan refers to the new facility.