Switch rustls crypto provider from ring to aws_lc_rs

[ChihweiLHBird]

Install aws_lc_rs as the process-wide provider at startup. ring is still compiled via transitive rustls features; removing it is a follow-up.

Replace the install helper with spin_tls::get_or_install_default_crypto_provider(), which returns the installed default, respecting a provider installed by embedders (the old helper would panic), and installs aws-lc-rs if none is set. The outbound client and trigger-http server TLS configs now build with aws_lc_rs provider explicitly.

Partially fix #3502

[lann]

rustls auto-detection would panic on paths that bypass Spin's entrypoints

Could you say more about this? Where would one need to bypass Spin's entrypoints? 🤔

[ChihweiLHBird]

rustls auto-detection would panic on paths that bypass Spin's entrypoints

Could you say more about this? Where would one need to bypass Spin's entrypoints? 🤔

Sorry... this is still a draft. The scenario in my mind was if another thing uses Spin as a crate and install ring as default. I know it's not supposed to be used this way, but in theory it might happen. So, I left that in draft and will refine it later.

[lann]

If something is embedding spin it should be able to pick the provider. If we're changing the default for spin up then that should just be scoped to the spin binary crate I think.

[ChihweiLHBird]

@lann the original way expects the default is not installed:

rustls::crypto::ring::default_provider()
    .install_default()
    .expect("failed to install rustls ring crypto provider");

It's from my previous PR #3590

The implementation in this PR is theoradically safer even though the panic scenario is very unlikely to be triggerred.

[lann]

Right but that is only called from spin trigger implementations (which are effectively the root binary crate in this case).

[ChihweiLHBird]

@lann Sorry for the confusion. I looked into it again, and found my earlier explanation was wrong.

Flipping the workspace rustls feature to aws_lc_rs does not remove ring, so without these guards of installing default and build ClientConfig with a specific provider via builder_with_provider, it may panic because 2 providers are compiled in. In many code paths, e.g. some spin tests, who doesn't call the install default helper, will panic, if without builder_with_provider.

Four tests in crates/factor-outbound-networking/src/tls.rs and tests/factor_test.rs all build a ClientConfig without going through a Spin entrypoint. That's what the builder_with_provider calls guard.

I can also split the helper into install_default_crypto_provider() (entrypoints only) and default_crypto_provider() for the config builders. Does that sound like a good idea?