aws-config signs DPoP proofs with RustCrypto, so credentials-login isn't FIPS

[yychen23]

#4681 routed SigV4 signing and request checksums through a FIPS-validated module, and the fips
feature on generated SDK crates and aws-config turns that on together with FIPS TLS. One
cryptographic operation in aws-config is not covered by it.

credentials-login signs DPoP (RFC 9449) proof JWTs with p256 ECDSA (ES256) in
aws/rust-runtime/aws-config/src/login/dpop.rs — alg: ES256, signed with
SigningKey::sign_with_rng. It is wired in as an auth scheme (AuthSchemeId::new("dpop")) whose
signer attaches the proof as a header, so it is a real signature on a request to AWS, in the
credential-acquisition path. RustCrypto is not CMVP-validated, so an application using
credentials-login with aws-config/fips does not have end-to-end FIPS, even though its request
signing, checksums, and TLS do.

Two related uses in the same crate are not part of this and are fine as they are: sso/cache.rs
hashes a start URL with SHA-1 and login/cache.rs hashes a session string with SHA-256, both only to
name a cache file. Neither is a security function.

Why it isn't a small change

The DPoP path doesn't have the same shape as the SigV4a signing this was already done for:

• it loads the key from SEC1 PEM (SecretKey::from_sec1_pem), where SigV4a derives a raw scalar,
• it exports the public key as a JWK, from public_key().to_encoded_point(false) split into x/y,
• it needs the fixed R‖S signature form for JWS (Signature::to_bytes()), not the DER that
  ECDSA_P256_SHA256_ASN1_SIGNING produces,
• the ECDSA nonce comes from rand::rngs::StdRng::from_entropy(), which is not a validated DRBG
  either. Routing this through aws-lc-rs would take its DRBG along with its ECDSA.

So this needs its own design rather than reusing aws-sigv4's crypto module, whose surface is
raw-scalar in and DER out.

Options

1. Route it through aws-lc-rs behind the existing fips feature on aws-config.
2. Make fips and credentials-login mutually exclusive with a compile_error!, so the
   incompatibility is loud instead of documented.
3. Document it as out of scope and leave the feature comment that's there now.

The current state is (3): aws-config's fips feature comment and the changelog both say so
explicitly.