Add support for GraalVM native-image

[cmdjulian]

This pull request adds support for GraalVM native image by using Spring Boot 3 native image support.
native-image requires reflection to be register beforehand.
@Reflectiv is used to register the methods called by the starter annotated with @MqttSubscribe to native-image,

Some reading material:

• https://www.justinpolidori.it/posts/20230599_spring_native_static_image/
• https://docs.spring.io/spring-boot/docs/current/reference/html/native-image.html
• https://www.graalvm.org/22.0/reference-manual/native-image/

[cmdjulian]

Regarding the testability of native-image, it's actually a little hard. Even Spring does it in a way, that they created a dedicated project they involve in a CI flow, basically a smoke test. I think we could come up with something as well, but the effort is quite high. When the supposed Spring bug is fixed, beside named parameters and the meta annotation @Reflective on the @MqttSubscribe as this method basically marks methods which are called reflectively, nothing else should be required.

I also created a small application testing it and it works as expected. That's how I found out about the missing reflection for cglib.

[rubengees]

Alright, thanks for the explanation. I would be fine without dedicated tests if they are hard to write once we get rid of the manual configuration as discussed above.

[cmdjulian]

I found a way to resolve the problem. The problems stems from the fact, that using @Lazy initializes a proxy which Spring seems to miss to register. The proxy is just a delegate to the underlying BeanFactory to retrieve the object up on first access. We can do that our self and even omit the proxy like this.
This is in line what Spring suggest for autowiring BeanPostProcessor, because of the aforementioned performance benefits to it. Let me know what you think :)
Now native works out of the box and we can even omit the expensive @Lazy.

One thing though, There seems to be no implementation for test of ObjectProvider available. So I just wrote it myself. We would not need that, if we abstract the collector away via an interface. The integration tests already take care of using the real implementation. If you don't like the self-written ObjectProvider I can also abstract the processor away if you prefer that.

Before changing that, I just wanted to make sure this is inline with what you prefer.

[cmdjulian]

Done, I'm looking forward to integrate this four improvements when the next release is created, any time table?

[rubengees]

Done, I'm looking forward to integrate this four improvements when the next release is created, any time table?

Sorry for the delay, I was a bit busy. I've released 0.17.0 with all the changes which will be available soon on maven central :slightly_smiling_face:.