[Build] Add chiabls subtree

[Fuzzbawls]

This introduces a new upcoming library dependency as a git subtree with support for native autotools (and CMake) builds.

#2405 had also introduced this library dependency, but only as part of the depends system, which introduced numerous issues, not least of which was essentially breaking any non-depends based builds. After some discussion, it was decided that the git subtree approach (as used with leveldb, crc32, univalue, and secp256k1) would be more ideal as it would allow for both depends and non-depends based builds.

Achieving this requires us to maintain our own fork of https://github.com/Chia-Network/bls-signatures (ours is at https://github.com/PIVX-Project/bls-signatures) with a native autotools based build system added to it (PIVX-Project/bls-signatures#1) that has been integrated into PIVX Core here.

Note: This PR simply introduces the new library and connects it to our autotools and CMake build systems, but does not introduce new code that actually uses the new library.

Also Note: This effectively bumps our minimum required version of CMake (for CMake builds only) to 3.14.

[random-zebra]

Huge concept ACK here.
Tested both gitian and local (non-deterministic) build.
Awesome job 🥃

Just one minor nit: let's not track relic_conf.h.in.
I added a temporary commit for this in 52b35cc, but it would be better to directly push the change the library, and update the subtree here.

[Fuzzbawls]

regarding the relic_conf.h.in file: it would go against the git subtree rules to exclude it's changes from being tracked here, or even in our forked bls-signatures repository, as doing so would add a conflict whenever we wanted/needed to update the relic version.

I wish git had a way to "un-track"/ignore an already tracked file, but the only solutions i've found only apply locally and cannot be applied as a general rule by default to anyone who clones the repo.

[Fuzzbawls]

Rebased to resolve conflicts after #2338 being merged.

This would be a good candidate to prioritize for merging before other conflicting PRs now, as rebasing subtree additions is not an automated process, and any dependent PRs (#2420 and #2421) will also need to do a more complicated rebase process until this is merged

[Fuzzbawls]

Also, for informational purposes, the relic_conf.h.in file can be forcibly ignored locally by issuing the following command:

git update-index --assume-unchanged src/chiabls/contrib/relic/include/relic_conf.h.in

This will ensure that any changes to the file are not considered when doing things like git add -A, and it will not show up in the list of modified files when doing git status or git diff.

I think this is an acceptable workaround that preserves git subtree rules and doesn't add an un-necessary layer of complication (being that the only other "proper" way of achieving this whilst having clean subtrees, would to also maintain our own fork of the Relic repository, which just seems overkill for such a minor issue). If need be, we can add the above command to the developer documentation.

[random-zebra]

ACK 73d32aa

[furszy]

Concept ACK, starting here and with all of DIP6 lecture, going to start with PIVX-Project/bls-signatures#1 and will back to this one. Then keep reading and reading.. lot of stuff.

[furszy]

I'm still moving forward through the DIP6 lecture (which is quite nice) and the PRs that were created in the https://github.com/PIVX-Project/bls-signatures repository (will review them all before giving my final approval here so we are fully sync).

Dropping few comments from the initial review:

• Compilation wise: all good. make and cmake, both completed properly ✅.
• The subtree hash matches correctly ✅.
• The BLS signatures sources aren't going to be affected by our custom libsodium requirement [WIP][Build] Libsodium upgrade & sanity checks #2358.
  The repository only uses libsodium for secure memory allocation (and can even be disabled). There is no problem with our consensus requirements for the latest libsodium Ed25519 pubkey and signature validation ✅.
• Need to add the new subtree into the into the developer-notes, "Subtrees" section.

Side from that, first glance, looking good. As said above, will finish the bls repo PRs review first and come back here, nice job ☕ .

[furszy]

just finished the review of the bls-sigs repo.

Worked some time there and found few things on the way:

• [Test] Complete test for Aggregated Shamir's Secret Sharing Scheme and DKG protocol. bls-signatures#8
• Removing unused PrivateKey operator*(const bn_t&, const PrivateKey&) bls-signatures#7

Better to merge them, and update this subtree with them. So the new Aggregated SSS scheme and DKG protocol test case can be run here as well and we don't utilize, by mistake, the operator with the infinite recursion.

[random-zebra]

I think that this can be rebased on master, and the subtree updated to PIVX-Project/bls-signatures@676ea45, so we can merge it and move forward.

[Fuzzbawls]

rebased on master and the subtree commit was updated. lets get this merged sooner rather than later as subtree updates are much more straight forward and simple than subtree adds (ie, if we need to update the subtree commit later then it is a simple process compared to rebasing a subtree add).

[furszy]

Tested local deployment once more, ACK c775ab3

[random-zebra]

utACK 5b289eb and merging...