Key-utils leak secret keys

[Fi3]

Secp256k1SecretKey in
https://github.com/stratum-mining/stratum/blob/dd64bf1c36ffd219cbc3a54846cde4e97361db6c/roles/stratum-apps/src/key_utils/mod.rs

can leak the inner secrets (Display impl, and Serialize and Deserialize). Key-utils should either be used only as a cli tool to derive keys or modified so that is safer, at least:

1. do not derive copy and clone
2. expose unsafe_inner_bytes(&self) or better unsafe_inner_bytes(self) but then we need to modify also the noise lib to own the secretes and not get a ref.
3. do not implement Display or do in a way that not leak the secret
4. zeroies the memory when drop (could still appear in stack traces btw)

[plebhash]

if we're not deriving Deserialize, then I guess we cannot load it from the config.toml?

storing secrets plaintext on a .toml file (along with other config parameters) isn't the most secure practice anyways, so perhaps this might be a good opportunity to completely re-evaluate the strategies around key management?

[plebhash]

here's a high-level suggestion from a UX perspective:

we refactor key_utils + config_helpers modules, such that all apps end up with this kind of CLI with subcommands:

./some_sv2_app -h

Usage: some_sv_app [COMMAND]

Commands:
  generate_privkey               Generate a password-protected private secp256k1 key for noise encryption, writing to disk
  run_with_test_privkey          Runs some_sv2_app while loading a default private key (⚠️ WARNING ⚠️ unsafe for production, only meant for testing ⚠️)
  run                            Runs some_sv2_app

the run subcommand takes the password-protected file via -k option, while the run_with_test_privkey loads the test key we're used to (mkDLTBBRxdBv998612qipDYoTK3YUrqLe8uWw7gu3iXbSrn2n), making automated testing easy.

options for run subcommand are similar to what we currently have (plus -k):

./some_sv2_app run -h

Usage: some_sv_app run [OPTIONS]

Options:
  -k, --key <KEY_PATH> Path to password protected file with private secp256k1 key [default: privkey]
  -c, --config <CONFIG_PATH>  Path to the TOML configuration file [default: some-sv2-app-config.toml]
  -f, --log-file <LOG_FILE>   Path to the log file. If not set, logs will only be written to stdout.
  -h, --help                  Print help
  -V, --version               Print version

whenever generate_privkey, run_with_test_privkey or run subcommands are executed, they print the base58 pubkey right in the beginning of the logs, so the user can easily copy-paste and share whenever needed

[plebhash]

I need to do more research to figure out the best way to do the password protected file, but secrecy crate seems an interesting option for protecting the key in-memory, after it's already been loaded and decrypted from disk