fix: don't print a secret key by default

[therustmonk]

Fixes for tari-project/tari#3822
Secret keys will never be printed until they are revealed explicitly with the .reveal() method call.

[CjS77]

Untested ACK. LGTM!

[CjS77]

Could you make this a blanket impl for T where T: SecretKey? Then any other Secret key impls get this for free

[therustmonk]

I've converted it back to draft, because an alternative solution available here: #114
We should compare them.

In any case we can't have a Debug trait implementation for another trait (SecretKey), but we can add a special wrapper that will guarantee safe behavior.

[hansieodendaal]

Interesting/nice use of the RevealedSecretKey struct.

On a side note (@CjS77 @stringhandler @deniskolodin), maybe I am missing the plot here? Do we not want to hide the secrets so it cannot be printed at all? Or is the idea that we go back and clean up all uses of .reveal() before mainnet?

[CjS77]

The latter.
The idea is to prevent accidental printing of secret keys anywhere.
This will happen in unexpected places.
For example Foo is a struct that derives Debug, and there's an identity field in Foo that also impls Debug. Let's say there's a secret key inside identity.
Now you're writing a function that deals with Foo. And you log some message about Foo during debugging.
You might not notice that you're printing out the secret key. And because it's a few levels deep, code searches might not turn it up either during routine security checks.
With this change, there's no problem, because the key field will automatically be redacted.
By requiring a call to reveal, the programmer is explicitly asking to provide the string representation of the secret key.

[hansieodendaal]

LGTM