Tighten-up config-set checking so that servers more reliably roll-back and recover from invalid changes
As reported to us via #14200:
We found a problem in how config-set is behaving when configuration has errors.
It is supposed to keep the old configuration, but instead the dhcp listener stops responding to DHCP requests.
The scenario in which this was uncovered was pre-production system in which there's a client polling every 5 seconds, then a process reads the running configuration and changes the id of one of the subnets from: "id": 1685525504, to: "id": "1685525504",
This incorrect configuration was due to a local process error but it is supposed to be handled by the config-set checking routine...
The error is logged as "invalid type specified for parameter 'id' (:0:15321)" and then the server is not receiving DHCP requests anymore, but still responds to commands from the ctrl-agent.
A restart is needed to unlock the service.
A log of the incident is available in Support ticket #14200