rndc reconfig/reload ignores changes to listen-on statements when port or interface address are left unchanged

One could change listen-on statements to change DNS transports without changing both port and interface addresses. For example, one could change a line:

listen-on port 1234;

to

listen-on port 1234 tls some-tls-config;

and then run rndc reconfig. However, that would not work because we lack a mechanism for changing listener type. Moreover, the example above will crash BIND with abort() because the code will try to update a TLS context on a listener that does not support TLS.

The problem was found while investigating issue #4518 (closed), which can be considered a special case of this issue: it can be described as a lack of ability to update/recreate listeners on reconfiguration.

The solution is to always recreate listeners on listener type change (e.g. Do53->DoT or enabling PROXY). That partially raises the issue mentioned in #3122 (closed), but there is no way around that except for allowing any process to bind "privileged" ports on affected platforms (read: BSDs). That might bring some troubles, but: It is a very edge case, as listener types do not change often. The fact that no one has reported the issue in at least two years or more proves that. We have no mechanism to dynamically change layers in an active listener, and it is hard to justify adding such a complex mechanism in the critical part of the code.

P.S. Historically, we would recreate listeners on reconfiguration for new transports in order to ensure that TLS certificates are reloaded, but we changed that (see #3122 (closed) and, to a lesser extent, #3415 (closed), as well as the related merge requests for additional details). That made this issue more apparent, although even back then, reconfiguration would have been broken for plain HTTP/2 listeners.