Config parsers should not discard existing configuration

[pivovarit]

Configuration parsers accept external config objects(MemberDomConfigProcessor(boolean domLevel3, Config config) { ... } ) but discard some of their insides and overwrite them with Java objects defaults which lead to issues like:

• External config override on advance networking public address looks also to override/default config element in same level #17681
• External config override for rest-api looks discarding optional second level of control for endpoint groups #17675

To avoid this kind of issue, config objects should initialize all their nested configuration objects and parsers should merely modify desired entries instead of discarding existing config objects and replacing them with new ones - this avoids an undesired effect of config entries being reverted back to defaults after using config overwrite mechanism.

This is just an umbrella issue to help track the progress. Multiple PRs are needed. To be backported to 4.1.1

[mmedenjak]

@pivovarit how much more do you assess is remaining? I see lots has been fixed already.

[pivovarit]

Most issues on the member-side are covered. I'd say that only very specific corner cases remain, but these are unlikely to be touched when working with config overrides. However, there are still a couple of issues on the client-side and I'm actually working on them (want to submit a bigger PR for them)

[Holmistr]

@pivovarit How is it going? We're getting closer and closer to the release, so if it's not really ready and won't be any time soon, we should move it out of 4.2 scope.

[pivovarit]

With my new recent assignments, I have a hard time dedicating time to them. Keep in mind that it's mostly done, so we can easily release what was merged so far