sources: add bottlerocket-crypto-provider crate

[sky1122]

Description of changes:
Add a centralized CryptoProvider crate that provides runtime FIPS detection and TLS algorithm selection for Bottlerocket Rust binaries.

When the kernel FIPS flag is enabled (/proc/sys/crypto/fips_enabled = 1), the provider restricts TLS to FIPS-approved algorithms only (AES-GCM cipher suites, P-256/P-384 key exchange). On non-FIPS systems, the full algorithm set is available.

This crate exposes three public functions:

• fips_enabled() - detect kernel FIPS mode
• provider() - return the appropriate CryptoProvider based on runtime detection
• install_provider() - install the provider as the rustls global default

Testing done:
Testing with this PR and these two code chunks running on both fips/non-fips fedora host and test pass on both

 cargo test --features http -p tough --test http test_fips_crypto_provider_e2e             
    Finished `test` profile [unoptimized + debuginfo] target(s) in 0.14s
     Running tests/http.rs (target/debug/deps/http-e659a739e99ce22d)

running 1 test
test http_custom_provider::test_fips_crypto_provider_e2e ... ok

test result: ok. 1 passed; 0 failed; 0 ignored; 0 measured; 3 filtered out; finished in 0.00s

Terms of contribution:

By submitting this pull request, I agree that this contribution is dual-licensed under the terms of both the Apache License, version 2.0, and the MIT license.

[sky1122]

forced pushed to rebase to the latest and regenerated the Cargo.lock file

[sky1122]

force pushed to address feedback

[sky1122]

forced pushed to turn on fips build and correct branch.

[sky1122]

forced pushed to address feedback change fips_enabled . For pub fn provider() -> CryptoProvider, I decide to keep return with no result and default handle the edge case to return true because I think if something unexpected happens, use the more restrictive mode. Breaking the caller (panicking or returning error) would prevent the binary from starting, which is worse than falling back to FIPS ciphers.

[arnaldo2792]

Two things:

• Lets fail if the read fails for whatever reason, we don't want to be in a situation where we use the wrong default (e.g. FIPS in non-FIPS setup).

• You could provide context of the error with snafu, like:

let fips_enabled_content = std::fs::read_to_string("/proc/sys/crypto/fips_enabled").context(error::ReadFipsEnabled)?;

fips_enabled_content == "1"

[arnaldo2792]

If fips_enabled returns an error with context, you can do this instead:

let (crypto_mode, provider) = if fips_enabled()? {
    ("FIPS", fips_provider())
} else {
    ("default",  default_provider())
};

info!("Using {} CrytpProvider", crypto_mode);
provider

[arnaldo2792]

We should have a test that validates that a client in FIPS mode can't talk to a server that doesn't support any of the FIPS ciphers when fips_provider is used.