feat: add static build config for MUSL

[nrdxp]

Description

Currently the node does not build totally statically due to the rocksdb crate. Newer versions of the crate do contain flags to statically compile, though, if we can find a way to update the transitive dependency cleanly.

Everything else is compiled in statically, including the MUSL C standard library

Checklist

• Commit sequence broadly makes sense and commits have useful messages.
• New tests are added if needed and existing tests are updated.
• Relevant logging and metrics added
• CI passes. See note on CI.
• Any changes are noted in the changelog.md for affected crate
• Self-reviewed the diff

Note on CI

If your PR is from a fork, the necessary CI jobs won't trigger automatically for security reasons.
You will need to get someone with write privileges. Please contact IOG Partner Chains developers to do this
for you.

[LGLO]

error: failed to run custom build command for `tikv-jemalloc-sys v0.5.4+5.3.0-patched`

Caused by:
  process didn't exit successfully: `/home/lglo/iohk/partner-chains/target/debug/build/tikv-jemalloc-sys-347c18ab3246c066/build-script-build` (exit status: 101)
  ...
src/malloc_io.c:107:9: error: incompatible pointer to integer conversion returning 'char *' from a function with result type 'int' [-Wint-conversion]
    107 |         return strerror_r(err, buf, buflen);
        |                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
  1 warning and 1 error generated.
  1 warning generated.
  make: *** [Makefile:479: src/malloc_io.sym.o] Error 

[skylar-simoncelli]

Nice!

I guess we need to sit on the draft PR until we upgrade the rocksdb crate to support the static link compilation

If we get this working can then integrate the changes in the CI and CD workflows

[nrdxp]

Yeah the rocksdb dep is transitive, which makes a bit more difficult to upgrade. However, if we really need this we could potentially still clean this up a touch and merge. Having only one dependency to keep track of in dynamic environments still reduces complexity and attack surface considerably

[LGLO]

if we really need this

• Nick sometimes needs partner-chains-node image to give to people so they can play with it
• we use the same (or similar) image for our tests

Providing a way to build partner-chains-node with statically linked dependencies has some value, but it really is not our business as long as the "demo/test" image is providing compatible dependencies.

If it turns out increase local or CI build times, I would rather think twice about it.

[nrdxp]

MUSL is lighter weight so it shouldn't really affect build times (at least it hasn't seemed to on my build server in testing).

I think the main benefit of static deps besides the improved simplicity of distribution is security, there is no way to inject a malicious dependency at runtime, which is a nice property. Still, since the current version of rocksdb leaves us hanging a bit, perhaps we can just leave off until the next update of the SDK