Enable Changing Public Key

[dnwiebe]

Now (after GH-622) the Node chooses a key pair when it starts for the first time, and keeps that key pair forever.

But while that's convenient, if you want large numbers of people to know how to contact your Node, it's not nearly as secure as having an agile public key that changes too fast for the bad guys to follow.

To that end, we need to be able to stimulate the Node from the command line to regenerate its key pair on startup even if there's already a key pair in the database.

• Start by modifying some SetupReporter tests to include --new-public-key: get_modified_setup_database_nonexistent_all_but_requireds_cleared switching_config_files_changes_setup get_modified_setup_database_nonexistent_nothing_set_everything_in_environment get_modified_setup_database_nonexistent_everything_set get_modified_setup_database_nonexistent_everything_preexistent get_modified_setup_database_populated_only_requireds_set

• Drive --new-public-key into shared_schema.rs between --neighbors and --real-user. Give it possible_values of on and off, with a default of off. If you're looking for an example, check out the --scans parameter: except of course --scans defaults to on, not off.

• Add --new-public-key to tests in node_configurator_standard.rs: privileged_parse_args_creates_configuration_with_defaults privileged_parse_args_creates_configurations privileged_parse_args_with_no_command_line_params These should drive the addition and population of a new field in BootstrapperConfig.

• In ActorSystemFactoryTools::cryptdes(), drive in the behavior to check the value of --new-public-key before reading the old key from the database. Remember, though: if you generate a new key, store it in the database over whatever already exists there.

• Edge cases:

  • Maybe PersistentConfig::cryptde() is None, but --new-public-key is off. In that case, panic with a message declaring that the user can't reuse an old public key the first time the Node is run.
  • Maybe BootstrapperConfig::db_password_opt is None, but --new-public-keyisoff`. In that case, panic with a message declaring that the user can't reuse an old key unless he first sets a database password.
  • If either of the previous two conditions are present, but --new-public-key is not specified and only defaults to off instead of being set by the user, a new public key should be generated and saved to the database if a database password is available.

[dnwiebe]

Test Plan

1. Install a brand-new Node. Try to start it with --new-public-key off. The Node should refuse to start with an error message complaining that there isn't any previous public key to use.
2. Establish a database password and start the Node normally without mentioning --new-public-key. Make a note of the public key it chooses.
3. Kill the Node and start it again, specifying the database password and with --new-public-key off. Ensure that the public key it uses this time is the same as the one it used last time.
4. Kill the Node and start it again, this time without specifying the password, but with --new-public-key off again. The Node should refuse to start, complaining that the lack of a password doesn't allow it to retrieve the old public key.
5. Kill the Node and start it again, specifying the database password, this time with --new-public-key on. Make sure the public key it picks this time is different from the one it's been using.
6. Kill the Node and start it again, this time specifying neither --db-password nor --new-public-key. It should come up with yet a third distinct public key.
7. Kill the Node and start it one last time, with --db-password but no --new-public-key. It should come up with the old public key from step 5.
8. That's it!