Now that #28013 is implemented we need to make sure that the bean definition is registered with the appropriate init and destroy method names.

Comment From: snicoll

I am blocked. I've added AotContributingBeanPostProcessor to the BPP that detects custom init and destroy methods. I am now left with the choice of mutating the RootBeanDefinition. From an AOT perspective, that's alright as the bean instance supplier is generated first (and therefore the contributors are invoked upfront).

From a context perspective, it is a little bit odd as MergedDefinitionBeanPostProcessor explicitly states that the methods of the base BeanDefinition class couldn't be invoked.

Looking at things from a generic fashion, if MergedDefinitionBeanPostProcessor did register those using the API that was created as part of #28103, then this PP shouldn't even have to be an aot-contributing. It kind of shows in the current implementation where it mutates the RootBeanDefinition if necessary and always return a null contribution.