Revert changes in config server bootstrapper and use new PropertyResolver class

[ryanjbaxter]

Reverts https://github.com/spring-cloud/spring-cloud-zookeeper/pull/325/files and https://github.com/spring-cloud/spring-cloud-zookeeper/pull/317/files and also address #324

Depends on spring-cloud/spring-cloud-config#2375

[ryanjbaxter]

@pantherdd I think this is ultimately a better solution to #324. It takes your idea of registering the Binder from the profile resolution code in Spring Boot and instead wraps that Binder in a class called PropertyResolver allowing it to all be encapsulated for the downstream code. The original code of ZookeeperConfigServerBootstrapper is basically restored with the only exception being he new use of PropertyResolver. Your custom Bootstrapper should also work as before except you would also need to use the new PropertyResolver class.

Note it depends on changes in spring-cloud/spring-cloud-config#2375

If you agree we can merge these changes and close #327

[pantherdd]

@ryanjbaxter Great news, thanks for giving this idea a try and making it work. I'm going to review this PR today.

FTR, the breaking changes (that this PR is reverting) were introduced to the 4.0.x branch in v4.0.1, so I'm using the following comparison of ZookeeperConfigServerBootstrapper to v4.0.0 to better see what the net changes are going to be: v4.0.0...ad32f45 (deep linking to the exact file doesn't seem to work :( )

[pantherdd]

With most of the earlier changes reverted, do we still need these to exist, or can we remove them too?

• ConfigServerInstanceProvider fields binder and bindHandler, and the 3-parameter constructor that sets them
• ConfigServerInstanceProvider.Function.apply(String, Binder, BindHandler, Log) default method

After this change, they seem to be dead code basically. Unless I'm missing some other use for them.

(Ref.: spring-cloud/spring-cloud-config#2269)

[ryanjbaxter]

Thanks @pantherdd! I have made your suggested changes.

Regarding the "dead code" in ConfigServerInstanceProvider, I agree this code is likely not needed anymore. Once we are satisfied with these changes, I will need to make similar changes in Spring Cloud Netflix, Consul, and Kubernetes which also have implementations. If I can use the same pattern there, the code won't be used anymore. Unfortunately since it made it out into a release (which is my fault) we can only deprecate the constructor for now and remove it in the next major.

[pantherdd]

Looks good to me, and the plan for the "dead code" sounds reasonable too.
Thanks! 🙂