掲題のpanicが発生したので、バグ修正までの流れを思考した内容を含めて時系列でメモしていきます。

仮説：
rustlsが0.23からcrypto moduleにそれまで使っていたringから、aws_lc_rs に変更した事に伴って、
rustlsの0.22を使っているモジュールと0.23以降を使っているモジュールが混ざった時、
デフォルトのcryptoモジュールが判別できずpanicが発生しているのでは。

関係ありそうな記事をリサーチ

rustlsのgithub repository上で、
ワードrepo:rustls/rustls no process-level CryptoProviderで検索

ワードrepo:rustls/rustls get_default_or_install_from_crate_featuresで検索

それっぽい原因のissueを見つけた。
Feature Request: Avoid panicking when ring and aws_lc_rs are both specified

要約すると、ライブラリのfeatureに、ringとaws_lc_rs両方が含まれていると、
panicが発生するということだった。（本件については2024/4/28時点で、まだ議論されていて解決していない）

yuna

調査していくと、
mail送信crateのlettre ver0.11.7のdependenciesが、
ring指定になっていた。

Cargo.toml

rustls = { version = "0.23.5", default-features = false, features = ["ring", "logging", "std", "tls12"], optional = true }

自プロジェクト内で、dependenciesにrustlsを明示的にfeatures指定なしで利用していた場合、
defaultでaws_lc_rsが使われるので、
ここで競合が発生してしまっているのでは、と思われる。

yuna

解決

dependenciesのrustlsのfeatureを、aws_lc_rsではなく、ringを使うように変更したら、
panicの発生がなくなった。

Cargo.toml

rustls = { version = "0.23.5", default-features = false, features = [
    "ring",
    "logging",
    "std",
    "tls12",
] }

http clientのreqwest crateでも、aws_lc_rsに対応する前のrustls0.22を使っているし、
aws_lc_rsは、少し様子みて使うほうが良いかもしれない・・・