Consider deprecating @EnableConfigurationProperties value attribute

[philwebb]

#23172 has introduced a new @ImportAsConfigurationPropertiesBean annotation which now means we have two very similar ways to import configuration properties classes. We might want to consider deprecating the value attribute from EnableConfigurationProperties.

There's one subtle difference between the two at the moment. If you import a class via @EnableConfigurationProperties, it will not use constructor binding unless the class itself has a @ConstructorBinding annotation. With @ImportAsConfigurationPropertiesBean, it will attempt to deduce if constructor binding should be used.

It's possible that a user may have an @EnableConfigurationProperties with a constructor that they expect to be autowired, and with getters/setters that they expect to be bound. The new annotation doesn't currently support this. We might be able to offer an additional attribute to deal with this, e.g.:

@ImportAsConfigurationPropertiesBean(type = MyBean.class, bindType = JAVA_BEAN)

[philwebb]

Requiring @ConstructorBinding annotations on @ConfigurationProperties beans is quite annoying in general. Perhaps we can investigate also adding an option to @ConfigurationPropertiesScan when we investigate this one.

I'd very much like a user to be able to define a constructor bound properties class without needing the extra annotation. We've investigated this before in #23216.

[Davio]

Would it be possible to end up with a default implementation where:

• A primary constructor is used if found (if it's the only constructor, otherwise it would be ambiguous which one we should use)
• Any leftover properties which are not set through the constructor are set by using setters (if possible).

[philwebb]

We'll consider this as part of #23607