Box.cfg should configure some parameters together, atomically

[Gerold103]

After #3186 we have a new setting: replication_anon. It is a flag affecting replication setting. Consider the problem we have now: assume, we update both replication and replication_anon. Sometimes it is not possible to update them in one box.cfg without 'surprising' behaviour. Below I describe what happens when we update replication and replication_anon depending on the anon initial value.

• replication_anon is changed true -> false
  • If we change anon before replication, then it will try to deanonymize the old replication before applying the new one. That is clearly a not expected behaviour;
  • If we change anon after replication, then it is not an error really, but it will connect to the new replication anonymously first, and then will try to execute deanon. Although it could have connected normally from the beginning.
• replication_anon is changed false -> true (Add a way to remove a replica from cluster space and make it anonymous #4708)
  • If we change anon before replication, then it will anonymize the old replication, and only then it will drop it and connect to the new one. Again, that is not a real error, but just unnecessary work. It could just drop the old replication.
  • If we change anon after replication, then it will connect to the new replication normally, and then will try to anonymize it. This is wrong. Because normal join can fail due to lack of ids, for example. And this is unnecessary work.

[Totktonada]

The expected behaviour would be IMHO:

• Remove upstreams that was removed from the replication option (ER_CFG: Incorrect value for option 'replication': duplicate connection with the same replica UUID #4668).
• Update (anonymize / deanonimize) existing upstreams.
• Add new upstreams from replication according to the new replication_anon value.