Prevent accidental change of network-key for active authorities

[alexggh]

As discovered during investigation of #3314 and #3673 there are active validators which accidentally might change their network key during restart, that's not a safe operation when you are in the active set because of distributed nature of DHT, so the old records would still exist in the network until they expire 36h, so unless they have a good reason validators should avoid changing their key when they restart their nodes.

There is an effort in parallel to improve this situation #3786, but those changes are way more intrusive and will need more rigorous testing, additionally they will reduce the time to less than 36h, but the propagation won't be instant anyway, so not changing your network during restart should be the safest way to run your node, unless you have a really good reason to change it.

Proposal

1. Do not auto-generate the network if the network file does not exist in the provided path. Nodes where the key file does not exist will get the following error:

Error: 
   0: Starting an authorithy without network key in /home/alexggh/.local/share/polkadot/chains/ksmcc3/network/secret_ed25519.
      
       This is not a safe operation because the old identity still lives in the dht for 36 hours.
      
       Because of it your node might suffer from not being properly connected to other nodes for validation purposes.
      
       If it is the first time running your node you could use one of the following methods.
      
       1. Pass --unsafe-force-node-key-generation and make sure you remove it for subsequent node restarts
      
       2. Separetly generate the key with: polkadot key generate-node-key --file <YOUR_PATH_TO_NODE_KEY>

2. Add an explicit parameters for nodes that do want to change their network despite the warnings or if they run the node for the first time. --unsafe-force-node-key-generation

3. For polkadot key generate-node-key add two new mutually exclusive parameters base_path and default_base_path to help with the key generation in the same path the polkadot main command would expect it.

4. Modify the installation scripts to auto-generate a key in default path if one was not present already there, this should help with making the executable work out of the box after an instalation.

Notes

Nodes that do not have already the key persisted will fail to start after this change, however I do consider that better than the current situation where they start but they silently hide that they might not be properly connected to their peers.

TODO

• Make sure only nodes that are authorities on producation chains will be affected by this restrictions.
• Proper PRDOC, to make sure node operators are aware this is coming.

[s0me0ne-unkn0wn]

As it makes the life of first-time node starters harder, could we include the node key generation logic in the post-install pipeline of the .deb package and Docker image?

[alexggh]

As it makes the life of first-time node starters harder, could we include the node key generation logic in the post-install pipeline of the .deb package and Docker image?

Done, although, I'm still concerned if it is wise to generate automatically keys at install, I've seen pipelines where part of producing your docker image for deployment you install all the required tooling, so in this case when operators would produce their v2 of the image they will get key on the filesystem and if they use the same image to run multiple nodes they might get into trouble because they would use the same key.

[alexggh]

@paritytech/release-engineering could you help me test the generated Deb and Rpm files after this PR. Thank you!

[bkchr]

Just misses a prdoc for Node operators, otherwise looks good.

Ty!

[alexggh]

Just misses a prdoc for Node operators, otherwise looks good.

Ty!

Done, merging ...