FIPS BoringSSL: provide a path for downstream consumers pinned to NIST-validated snapshots

[Sanchit-20]

Problem Statement

PR #39017 changed boringssl_fips to use the BoringSSL Update Stream (rolling main branch) instead of pinning to a NIST-validated snapshot. The PR cites FedRAMP policy as the rationale.

Validated snapshots are required by some federal compliance frameworks, where the Update Stream model is not currently accepted by accreditation bodies.

After PR #39017 the only path for affected downstream consumers is to maintain a patch that re-introduces a boringssl_fips entry pointing at a fips-YYYYMMDD branch with an active NIST CMVP certificate.

This patch is fragile in two ways:

1. No documented API floor per Envoy release. PR #39017 also removed all #if BORINGSSL_API_VERSION >= N guards from the TLS code (visible in the diff for context_impl.cc and default_validator.cc). Envoy now calls newer BoringSSL APIs unconditionally. There is no documented way for downstream consumers to know in advance whether a given Envoy version is compatible with a given validated snapshot — the first signal is a compilation failure.

2. NIST validation cadence lags BoringSSL bumps. Validated snapshots are published roughly annually (most recent: cert #5104 / fips-20240407, BORINGSSL_API_VERSION = 32); upstream Envoy bumps the BCR boringssl tag every few months, ratcheting the API version forward. The gap only widens.

Proposal / Ask

1. A first-class, documented mechanism to build FIPS Envoy against a specified BoringSSL snapshot. The Update Stream model would remain the default; this would be an additional supported path for downstream consumers that need to pin to a NIST-validated snapshot.
2. BORINGSSL_API_VERSION gates around APIs that may not be present in older validated snapshots, so the build fails gracefully (or compiles with degraded but functional behavior) instead of producing a hard compile error against any snapshot below a certain API version.

xref: #38353