Suppress CGLIB validation WARN for lifecycle callbacks

[seonwooj0810]

Closes gh-35365

What's going on

CglibAopProxy.doValidateClass walks every method of the proxy super class and, for each public final method that overrides an interface, logs at WARN:

Unable to proxy interface-implementing method [public final void X.afterPropertiesSet() throws java.lang.Exception]
because it is marked as final, consider using interface-based JDK proxies instead.

For methods that come from Spring's configuration callback interfaces (InitializingBean, DisposableBean, Aware sub-interfaces, Closeable, AutoCloseable) that recommendation is misleading on multiple levels:

• The user typically cannot make the method non-final - it's final precisely because the framework (or a base class like WebServiceGatewaySupport) wants to guarantee the lifecycle step runs.
• JDK proxies wouldn't help: the surrounding class is usually targeted by a class-level pointcut (e.g. @Timed, @Transactional) which means CGLIB is the only viable proxy mechanism anyway.
• Application code virtually never advises afterPropertiesSet() / destroy() / set*Aware(...) itself, so the missed advice the warning hints at doesn't actually exist.

The result is alarming noise during startup for users who run WebServiceGatewaySupport, JmsGatewaySupport, or any of the other framework base classes with a final afterPropertiesSet() together with a class-level AOP annotation. The reproducer in the linked issue (a bare-bones class with final afterPropertiesSet() + @Timed) triggers the WARN.

The change

doValidateClass now uses a small helper, implementsOnlyConfigurationCallbackInterfaces, that returns true when every interface declaring the method is one of the configuration callback interfaces enumerated in ProxyProcessorSupport#isConfigurationCallbackInterface. The WARN about an interface-implementing final method is skipped in that case, and the existing DEBUG-level diagnostic in doValidateClass (which already explains the consequence in detail) is retained for users who want the information.

Two cases continue to log the WARN unchanged:

• Public final methods that don't implement any interface (still bad - the "Public final method [...] cannot get proxied via CGLIB" message).
• Public final methods declared by both a callback interface and a user-defined interface with the same signature - the user interface signal takes precedence, so the warning still fires.

The helper deliberately mirrors ProxyProcessorSupport#isConfigurationCallbackInterface rather than reaching across to call it, so the public API of ProxyProcessorSupport doesn't change and the two classes stay independent.

Verification

• Added CglibAopProxyConfigurationCallbackTests with seven cases covering InitializingBean, DisposableBean, BeanFactoryAware, Closeable, a user-only interface, a method shared between a callback and a user interface, and a standalone final method without any matching interface.
• ./gradlew :spring-aop:test (full module) - green.
• ./gradlew :spring-context:test --tests "*Proxy*Tests" --tests "org.springframework.aop.*" - green, exercising the CGLIB validation path through the broader proxying machinery.

Verification done: (1) confirmed no in-flight PR via gh pr list --search "35365 OR final afterPropertiesSet OR doValidateClass" and the linked-PR query on the issue, (2) no claim comments on the issue thread, (3) fix touches .java only (CglibAopProxy.java + a new test), (4) grepped main for the Unable to proxy interface-implementing method string - still present in CglibAopProxy.java:295, (6) maintainer @snicoll transferred the issue to spring-framework with "I wonder if Spring Framework could do something about this" and replicated the noise on a bare-bones project, which is the engagement signal I targeted.