Build Script requires network access

[ala-mode]

While working on StageX Reproducible Build I noticed the current build script for zingolib requires network access in at least one place. This logic looks like it went in about 9 months ago and was last adjusted about 4 months ago. There is one other place it looks likely that a network call is needed too, but I did not observe this working, directly.

This logic makes it impossible to control the hermeticity of the build. That is, it defies the structure which is used to make the build reproducible: this is a blocking problem for this PR.

More abstractly, this pattern implicates a number of issues:
-network calls during builds introduce flakiness, additional security risks, possibly add latency.
-it can break or make impossible offline or cached builds.
-possible non-determinism.
-it runs counter to rust's compile-time guarantees (could possibly bring in unverified external code, bypassing Rust’s safety checks).
-adds debugging complexity.
-create 'hidden' dependencies that are not tracked by cargo or git directly.

I am not sure of the pattern to fix this issue right now, but I am fairly certain this is a bad pattern beyond it blocking the PR I am looking at. Here's a few rough thoughts:
-check for params, and download params at (first) runtime, not build time.
-provide a utility script or cli subcommand to download params.
-if needed for CI run as pipeline script

[dorianvp]

The runtime approach is what zcashd uses, but I am concerned about how well it would integrate with platforms like Android, as they rely on that file being present... However, it does sound like the cli / utility script might be the way to move forwards. I'll look into this. There is some ongoing work already on the FFI side here: #2145. I'll take these problems into consideration for the FFI architecture.