eliminate openssl dependency for consensus bits

[spoonincode]

Given what occurred in openssl 3.0.4 I'd like to see us move away from using openssl in consensus bits.

Proposal: use a submoduled-in static linked boringssl for consensus bits; i.e. anything in libchain. I already explored this some previously in EOSIO/eos#9026 and it's a clean drop in replacement likely with low risk of something behaving differently (unlike, say, if we completely rewrote the R1 recovery code with a different library).

Problem: While we want to fix the consensus mathy stuff at a long term version, but we don't want to fix TLS stuff -- that will likely need to be bumped in the future for new TLS versions, security fixes, etc. We can't have two different versions of boringssl or boringssl+openssl linked in the same executable because of symbol conflicts. This causes grief in finding a good solution.

Proposed solution: Abandon openssl altogether. But what do we do about TLS in our applications?

cleos

Reimplement HTTP requests via platform provided high level HTTP APIs. This would mean libcurl on Linux, NSURLSession on macOS, and WinHTTP on Windows. This actually has a number of nice benefits like getting cleos HTTP/2 support, system proxy support, ipv6 happy eyeballs, and not needing to deal with the CA store. The downside of course is that it's more code to maintain and different across platforms.

nodeos & keosd

My preference would be to eliminate TLS support in nodeos & keosd. I suspect usage of the HTTPS server in nodeos is extremely rare (some prominent community members regularly discourage its use, even). Likewise, I suspect connecting nodeos to keosd via TLS is extremely rare.

If we must keep TLS support in nodeos & keosd, perhaps look in to system provided TLS implementations such as GnuTLS and Core Transport.

Need to be mindful of #110 & eosnetworkfoundation/product#13 as they mix in to these decisions too. This effort is likely a blocker for eosnetworkfoundation/product#20.

Explore: Previously, as mentioned in the EOS PR above, boringssl's sha256 performance was rather poor. This is important to us. Performance testing with sha256 & r1 key recovery should be performed on the latest version before getting too far in to this change.

[stephenpdeos]

This issue will close/replace #362

[stephenpdeos]

@spoonincode can you document the big questions we need to answer before this is actionable?

[spoonincode]

Any performance testing should probably look at making #786

[stephenpdeos]

We'll utilize the work done in #786 to benchmark performance impact

[spoonincode]

This is much easier to accomplish once #110 is settled.

[spoonincode]

Tracked in leap repo now