Don't implement `Display` for `@sensitive` string shapes and don't `#[derive(Debug)]`

[david-perez]

We currently newtype constrained string shapes. When they are marked as @sensitive:

@sensitive
@length(min: 1, max: 69)
string Password

We also implement Display:

impl ::std::fmt::Display for SchemaJson {
    fn fmt(&self, f: &mut std::fmt::Formatter<'_>) -> std::fmt::Result {
        "*** Sensitive Data Redacted ***".fmt(f)
    }
}

and derive Debug:

#[derive(
    ::std::clone::Clone, ::std::cmp::Eq, ::std::cmp::PartialEq, ::std::fmt::Debug, ::std::hash::Hash,
)]
pub struct Password(pub(crate) ::std::string::String);

• Don't implement Display. Implementing Display is footgunny. If you have a fn save_password_to_database(password: String), calling save_password_to_database(password.to_string()) seems like would make sense, but would cause permanent data loss. Users should instead use the generated password.into_inner(), so it's better to point them in that direction by avoiding implementing Display.

• Don't #[derive(Debug)]. While Debug should format in a programmer-facing debugging context, debugging with the redaction should suffice.

  • Note that this is consistent with how Debug is implemented throughout smithy-rs e.g. the Debug implementation for a structure shape that has member shapes that target @sensitive string shapes will print the struct with redactions for the @sensitive strings.
  • We can feature-gate a "truly unredacted" debugging experience, like we already do with sensitive.rs; see RFC: Logging in the Presence of Sensitive Data.

[david-perez]

This issue is related (but separate) to #1883, which is concerned about whether a @sensitive un constrained string shape should be newtyped or not.