Rationalize Spring Boot configuration keys

[snicoll]

During its early development Spring Boot has started to take a set of root prefixes for configuration such as spring (obviously) but also a few others: management, server, endpoints, logging, security, multipart, error. We also have root prefixes for 3rd party integration (liquibase, flyway, jolokia).

We want to push for a reserved namespace for the keys that Spring Boot is exposing so that we can guarantee a stability over time. We can't do that with the current namespaces that we are holding.

I think we should come with a clear policy that would avoid some unfortunate decision. error actually exposes one property at this point which is the path of the Spring MVC view to use in case of error. Could as easily have been spring.mvc.error or something...

[shakuzen]

👍

[arnosthavelka]

👍

[snicoll]

See also #2020

[snicoll]

As part of this issue we should also avoid at all cost mixing our own property POJO with 3rd party binding.

Typical example: Flyway. In FlywayProperties we have a locations property of type List<String>. InFlywaywe have alocationsproperty of typeString[]. When you set a comma-separated value, both values are injected just fine. If you use an indexed value (typically with YAML) then it blows up becauseFlyway.getLocations()` returns a new array every time and the binder fails to realize this is the "same" value somehow.