Enable Changing Public Key #623

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.