Add `linux-musl-x64` Runtime Support

[adamrodger]

This is required for running PactNet inside Alpine containers, for example.

[adamrodger]

Requested in upstream change: pact-foundation/pact-reference#185

[adamrodger]

Available in FFI 0.2.3

[adamrodger]

I started to add this but it's not going to work. The FFI for musl currently only outputs a static .a library, whereas .Net only supports loading shared libraries (.so, .dll, or .dylib).

I did manage to get the FFI to build a shared library (.so) on a musl target with some additional Rust flags:

RUSTFLAGS="-C target-feature=-crt-static" cargo build

rustup show
Default host: x86_64-unknown-linux-musl
rustup home:  /usr/local/rustup

1.59.0-x86_64-unknown-linux-musl (default)
rustc 1.59.0 (9d1b2106e 2022-02-23)

ls -alh target/debug/*.so
-rwxr-xr-x    2 root     root      207.1M Mar  5 16:54 target/debug/libpact_ffi.so
-rwxr-xr-x    2 root     root      119.1M Mar  5 16:52 target/debug/libpact_verifier.so

However, there are a few problems here:

1. It's 207MB, which is massive for shipping inside a NuGet
2. It has the same name as the linux-x64 version, and .Net doesn't have a way to detect musl inside the csproj (unless it's a hack and brittle way like checking the OS string for Alpine or something)
3. That's a very non-standard build for a musl target with Rust, as mentioned in the issue rust-lang/rust#44991

I think, for now, I'm gonna close this one as wontfix unfortunately. I just can't see the effort being worth it at the moment, and by the sounds of things we're likely to have problems even if we could get the packaging working.

@uglyog It may be that we can actually remove the musl FFI build, sorry for the inconvenience. A .a is no use to interop and that's just what the standard musl builds on Rust produce.

[adamrodger]

Correction to the above: the release build is actually 25.8MB. The debug build was 207.1MB.

[uglyog]

I can look to update the FFI build with those flags