Deprecate support for injecting DynamicPropertyRegistry in favor of DynamicPropertyRegistrar beans

[wilkinsona]

This follows up on #41839, and in particular:

I've put a work-around in for M2, but I think we might need a better long-term solution. In hindsight, we should probably not have used DynamicPropertyRegistry but instead have our own interface.

[snicoll]

A DynamicPropertyRegistry bean does not provide any built-in resolution mechanism and the @Bean method that's invoked to mutate the Environment may easily be invoked after the related component has been created. This may cause issues that are very hard to track. As a framework mechanism without an intuitive (or out-of-the-box) mechanism to deal with this issue, one should wonder if it should be exposed at all until it does.

We need to have a discussion with the framework team about this.

[wilkinsona]

I've prototyped some changes to Boot that make use of Framework's new DynamicPropertyRegistar. The prototype currently needs to use reflection as Framework's DynamicPropertyRegistrarBeanInitializer is package-private. I've opened spring-projects/spring-framework#33593 to see if Framework can provide use with an SPI for bootstrapping the DynamicPropertyRegistrar support outside of the test context framework.

[wilkinsona]

The bean initializer's now public so the prototype no longer needs to use reflection. The prototype's been updated to this effect. I think this is pretty close now but I'd like to have another round of discussion with the team, particularly around how we bring the deprecation to people's attention.

[wilkinsona]

We'd like a failure by default rather than just a warning. We'll then provide a property to change this behavior with supported values being something like fail, warn, or ignore. fail would be the default.