Auto-generated bindings for aws-lc-fips-sys v0.12.6

[justsmth]

Description of changes:

• Update aws-lc-fips-sys to 0.12.6 to align with AWS-LC-FIPS 2.0.9
• Auto-generation of bindings for aws-lc-fips-sys.
• Provide pregenerated bindings for 4 more platforms: "x86_64-apple-darwin", "aarch64-apple-darwin", "aarch64-unknown-linux-musl" and "x86_64-unknown-linux-musl"
• Added a CI job to build/test FIPS build with LTO enabled.

Testing:

Bindings generated by this workflow run: https://github.com/aws/aws-lc-rs/actions/runs/8346539433

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and the ISC license.

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 95.82%. Comparing base (2298ca8) to head (3e70628).

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #372 +/- ## ======================================= Coverage 95.82% 95.82% ======================================= Files 60 60 Lines 7865 7865 ======================================= Hits 7537 7537 Misses 328 328 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[Mark-Simulacrum]

Defaults to dynamic build for FIPS (except for "musl" or when AWS_LC_FIPS_SYS_STATIC is set in environment).

Is there a reason for this documented somewhere? In general static builds are fairly idiomatic for Rust so this sounds surprising to me.

Instead of conditioning on musl I'd probably recommend crt-static target feature (see https://rust-lang.github.io/rfcs/1721-crt-static.html for some docs), that is probably more in line with matching libc linkage across lots of platforms. (Note that there's a long-standing ask from musl upstream that Rust stops statically linking by default, since that's not what you want on musl distros like Alpine).

[justsmth]

Is there a reason for this documented somewhere? In general static builds are fairly idiomatic for Rust so this sounds surprising to me.

There are a few reasons for this that are fairly specific to "FIPS":

• The FIPS standard requires a "self-test" at runtime to verify a hash of the contents of the FIPS module. The concern with a static build is that this hash might get broken by link-time-optimizations (LTO).
• Our static build of the FIPS module is only supported on Linux for x86-64 and aarch64. The reason for this is complicated, but it relates to our need to eliminate relocations (due to having position-independent code) in order for the FIPS module contents hash to not get changed. We call the process of eliminating relocations the "delocation", and it requires parsing and restructuring of assembly code. This "delocation" logic is currently implemented in Go, which is one reason why our "FIPS" build requires Go.

Thus, we can perform the shared build of the FIPS modules across many more platforms than we can with static, and the shared build is less likely to be affected by LTO.

[justsmth]

To avoid potentially breaking downstream builds/deployment, the default build of aws-lc-fips-sys on Linux (x86-64 and aarch64) remains static in this PR.