ArC - handle types of removed beans more leniently

[mkouba]

• log a warning if unable to load a bean type of a removed bean
• previously the app failed at startup
• resolves Removal of beans loads referenced classes #24338

[mkouba]

Note that this modification makes the bytecode of the generated ComponentsProvider.addRemovedBeansX() methods a bit more complex because we wrap every removed bean with a try-catch block and furhermore the caching is less effective in the sense that we need to duplicate the "type loading" logic (previously the logic was only included once per a ComponentsProvider.addRemovedBeansX() method). However, it should not have any memory effects, i.e. the allocations should be the same as before. Also note that the java.lang.reflect.Type cache is now shared accross all ComponentsProvider.addRemovedBeansX() methods.

[manovotn]

I've looked at the generated ComponentsProvider class with and without the changes in this PR and I think it looks good!

[mkouba]

I've looked at the generated ComponentsProvider class with and without the changes in this PR and I think it looks good!

Ok, let's run the CI then...

[quarkus-bot]

Failing Jobs - Building cf38835

Status	Name	Step	Failures	Logs	Raw logs
✔️	JVM Tests - JDK 11
✖	JVM Tests - JDK 17	Build	Failures	Logs	Raw logs

Full information is available in the Build summary check run.

Failures

⚙️ JVM Tests - JDK 17 #

- Failing: integration-tests/grpc-hibernate-reactive 

📦 integration-tests/grpc-hibernate-reactive

✖ com.example.reactive.ReactiveServiceTest.shouldWatchAndAddMultipleTimes - More details - Source on GitHub

java.lang.RuntimeException: java.lang.RuntimeException: Failed to start quarkus
	at io.quarkus.test.junit.QuarkusTestExtension.throwBootFailureException(QuarkusTestExtension.java:632)
	at io.quarkus.test.junit.QuarkusTestExtension.interceptTestClassConstructor(QuarkusTestExtension.java:703)

[gsmet]

The test above has been flaky lately. /cc @DavideD @michalszynkiewicz

[michalszynkiewicz]

@mkouba I think the problem is that the order between HibernateReactiveProcessor#setUpPersistenceProviderAndWaitForVertxPool and GrpcServerProcessor#initializeServer is not deterministic.

[michalszynkiewicz]

This should fix the test failure: #24420 but I'm not able to reproduce it locally (tried 100 times with no failure).