Spring Classpath-based filtering of the native configuration generation

As a follow-up of #27991 and #28160, a filtering on the generated configuration should be done based on classpath checks using reachableType for all hints + reflection/proxy/serializable types. This will allow to reduce the amount of configuration generated.

Comment From: bclozel

We've introduced the ConditionalHint contract in #28126 that we could leverage here. I'm wondering how generally applicable it is. Isn't it possible to add a typeReachable condition that's based on a class that's not present in the runtime classpath at build time but might be present at runtime? I'm thinking about java classes generated during the AOT phase. Or should we document that limitation and avoid using AOT classes as conditions in hints?

Comment From: snicoll

I am not convinced of the impact of this to be honest. We're already invoking RuntimeHintsRegistrar conditionally and the rest of the API is based on browsing the BeanFactory and registered beans with a closed-world assumption. The above is a far more superior filtering strategy than looking at the reachable type.

However, hints that are registered statically (in aot.factories) could contribute things and provide a reachable type. If they do using a class, invoking them will fail in the type is not present. Remains the case where they're using a TypeReference. From that perspective, I don't think we should care too much about AOT generated classes in conditions as statically registered factories don't really have access to that.

Comment From: bclozel

Now that we've evolved the AOT processing phase, it seems that we're contributing RuntimeHints in a dynamic fashion that already takes the classpath into account.

The typeReachable information should instead be used by contributions to signal that while the required dependency is on the classpath, we don't know if the hint will be useful since it depends on some type being reachable during the GraalVM static analysis. This can be especially useful for hints linked to clients (HTTP, RSocket, etc) since we don't necessarily know if they'll be used at runtime without knowing the actual method bodies.

For now, we don't have a use case for filtering hints based on their typeReachable information during the AOT phase. I'm closing this issue for now, we can revisit this decision if such a use case is found.