initial_predicted_ports and handling during reconfigure
Currently (if the docs are to be believed) an attempt to change this field on reload causes an error.
IMO this is wrong. Fields that genuinely affect only the startup ought to be freely changeable. Otherwise you might change the on-disk config file intending to have this change at next restart, and then find that you cannot make other config changes.
However, ISTM that for this specific field, there is a more fundamental problem. This parameter is used for preemptive circuit constrution. Declaring a new set of ports for which we want to now preemptively build circuits seems like a meaningful thing to do at runtime. So, the parameter has the wrong semantics (and the wrong name).
Combining, during reload, a new set of configured ports with the ones discovered during runtime, is left as an exercise to the implementor. I think any plausible algorithm will do.
I am not tagging this as an API break, because we need to be able to evolve the config file without breaking changes. See also #285.