Avoid requiring manual munges of `config.toml` to switch build target architecture

[bleggett]

Right now for both CI and local builds we require manual munges of .cargo/config.toml BSSL_* env var paths, to point https://github.com/cloudflare/boring at the right vendored FIPS build for the target build architecture.

We are currently unable to intelligently switch these vendored paths our own build.rs due to logic https://github.com/cloudflare/boring has in its own build.rs

We have three options here if FIPS-only builds remain the default:

1. Let https://github.com/cloudflare/boring leverage it's own boringssl autobuild logic, and stop shipping vendored binaries in our repo -> this places significant FIPS-related restrictions on local build boxes. This could be mitigated with a containerized build env.

2. PR changes into upstream https://github.com/cloudflare/boring to enable it to dynamically select the correct vendored boringssl library path based on build target arch -> this may be too much "intelligence" to push upstream, but we can try.

3. PR changes into upstream https://github.com/cloudflare/boring to enable our downstream build.rs to dynamically select the correct vendored boringssl library path based on build target arch.

[stevenctl]

https://github.com/rust-lang/pkg-config-rs#external-configuration-via-target-scoped-environment-variables

~Possibly viable?~

Misread it. But their approach might be?

[bleggett]

https://github.com/rust-lang/pkg-config-rs#external-configuration-via-target-scoped-environment-variables

~Possibly viable?~

Misread it. But their approach might be?

Yep could be.

Ideally I would prefer to fix upstream boring so it respects whatever BSSL_* vars are already set by parent crates, and do any fancy stuff (e.g. autoselection) in our own build.rs, as I think that's both reasonable and simple.

The boring crate then has a behavior of

• Nothing set by parent crate? Let me build boringssl with my own logic (what it does today).
• Parent crate supplying vendored libs? I should do nothing but expect them to be there (what it probably should do today but doesn't, quite).

[howardjohn]

After https://github.com/istio/ztunnel/pull/820 this should no longer be required by default. If you want to build with boringssl you would need to still, though.