Allow persistently changing config values from command line

[jstuczyn]

With introduction of #386 you are no longer allowed to initialise another node/client/gateway with the same id as an existing one. However, what if user wants to change some configuration and use it in all subsequent runs? For example he might want to change his announce-host because he updated his DNS record. If he wants to try this change once, he can already do it by simply passing --announce-host flag in run. However, if he wants always use the new value instead, he has to either manually change config.toml file or we could introduce extra flag like --save-changes in run.
Alternatively allow for flag that bypasses the check in init (I've got a feeling it would make our lives easier while developing...)

[futurechimp]

Let's talk about this, probably with Alexis who is a good proxy for a node operator, to see that we do it in the way which will be most convenient for mixnoders.

[jstuczyn]

I can already say that init bypass will be very useful for us. Already run into that issue today : )

[futurechimp]

The main thing we care about is that a re-init won't blow away the user's keys. Losing keys means that all mixnode uptime history is lost, and so is all the valuable reputation the operator has racked up. If you run a solid mixnode, people will want to stake on you. Losing your keys means that there's nothing to stake on, and it's bad news for the node operator. I think this is what we're primarily concerned about.

[futurechimp]

I've been thinking about this some more, and to me it seems like we don't need an extra flag to achieve this (that would just make things more complex). We just want init to work like it does now, save all values etc. But if there are already keys for this id, we leave them in place rather than regenerating them.

Does this make sense?

[jstuczyn]

So what you're suggesting is init with existing id would overwrite everything, but the keys (if they exist)?