…ere possible (First)

400f6f4 Moving uint256(str) to proper uint256S(str). --> uint256 string parse. (furszy)
b0163f6 x=0 moved to x=UINT256_ZERO (furszy)
14319cf [Backport] Replace uint256(1) with static constant. (furszy)
d96eab9 Replace GetLow64 with GetCheapHash (furszy)
741f43c Replace direct use of 0 with SetNull and IsNull. (furszy)

Pull request description:

  Initial PR towards a big back port [upstream#5490](bitcoin#5490).

  This is including:

  1) [upstream@4f152496](bitcoin@4f15249)
  Replace x=0 with .SetNull(),
  x==0 with IsNull(), x!=0 with !IsNull().
  Replace uses of uint256(0) with UINT256_ZERO.

  2) [upstream@80765854](bitcoin@8076585)
  Replace GetLow64 with GetCheapHash

  3) [upstream@2eae3157](bitcoin@2eae315)
  Replace uint256(1) with static constant

  4) Moved `uint256(str)` string parse to the adequate `uint256S(str)`method.

ACKs for top commit:
  random-zebra:
    ACK 400f6f4 and merging...

Tree-SHA512: ed34b398ff00df8584efe079c764756d17bf5d7f1406aa6db84f82d9b544ae2b996c9b9e811d9d54989002a1f620ed798f77aa9e5b5d6c00a4de8310c5d6534e

d7ba881 Add missing blob/arith uint256 files to CMakeLists (furszy)
f05a97a Stack around the variable 'rv' was corrupted. (furszy)
2371666 arith_uint256 test back ported (includes arith_uint160 checks inside too) (furszy)
7d43a4b Migration process: uint256 main methods removed, using arith_uint256 for now. (furszy)
3669b9c uint512 modified to use the `blob_uint256` base class. New uint files added to makefile. (furszy)
7ca1fea arith_uint256 files created. (furszy)
21f824c Base blob uint256 files created. (furszy)

Pull request description:

  This is part of the large effort of making the uint256 file an opaque blob object and not treat every uint256 as an arith_uint256 anymore (same for the uint160 and uint512). Work coded on top of #1395, this is the second step.

  As we cannot do it all at once, i opted to do the migration in steps.
  The amount of changes needed is really extensive and the risk of damage the synchronization process -and other areas as well- is high, this will need changes on the MNs, budget and zerocoin library sources which are using the uint256 object purely as a number.

  This step is doing the following changes:

  1) Creating blob_uint256 files (opaque blob version of the uint256 files -- this is the future uint256 files that will be refactored once all of the fields that are using it as a number in our sources get migrated to use the new arith_uint256 classes).

  2) Creating arith_uint256 files.

  3) Cleaning shared code between the uint256 file and the arith_uint256 classes and only leaving in uint256 the old classes that needs to be checked and migrated -- if them are using the uint256 as a number and not as an opaque blob object -- (following the explanation in point 1).

  4) Updating, cleaning and connecting the arith_uint256 unit test (including arith_uint160 and arith_uint256 checks and validations).

ACKs for top commit:
  random-zebra:
    All good now 🍻 ACK d7ba881
  Fuzzbawls:
    ACK d7ba881

Tree-SHA512: 8f4561196c6dbf377a6c071b5dd2a329c819824ddcdb4774d5a610f9601f4df475993887349d1df5292b061090682d8f05803a302cdd2edabf9e3645dc1070e2

dea250c [Core] Migrate uint160 (CKeyID/CScriptID) to opaque blobs (random-zebra)
86a106e [Tests] Use arith_uint160 instead of uint160 in uint256_tests (random-zebra)
12240dc [BUG] fix a few places improperly checking boost::get<CKeyID> (random-zebra)

Pull request description:

  Keep going with the migration started in #1395 and #1414.
  This time migrate the whole class `uint160`, so it is defined as a child of `base_blob` (essentially replace `uint160` with `blob_uint160`), thus migrating `CKeyID` and `CScriptID` as well.

  Since opaque blobs (unlike the `arith_uint` classes) have trivial copy-assignment operator, this fixes the "scary" `-Wclass-memaccess` warning reported in #2076 (tested before/after patch, with gcc v9.3.0)

  Bonus: this fixes also a minor bug found along the way: few places where we are checking the result of `boost::get<CKeyID>` over the pointed `CKeyID`, which shouldn't even have a `bool operator()`, and might even be un-initialized (though we always verify `IsValidDestination` before, so this is mostly redundant) instead of checking the pointer itself.

ACKs for top commit:
  furszy:
    looking good, utACK dea250c
  Fuzzbawls:
    utACK dea250c

Tree-SHA512: 2e6d6e2adfcd8a1c32941f0480b882ea801fe1816eaa0c5050efc506c0aa09f6d589d53fb13798a17ffd2858021c3a0ccd50465acbc7d5c5a71dc0fb0f398756

722759d [Refactor] Remove arith_uint256::GetCheapHash() and fix uint256 implem. (random-zebra)
a640051 [Refactor] uint256: update GetHex() and SetHex() (random-zebra)
bce58ac [Refactor] uint256: raname data --> m_data and make it protected (random-zebra)
4ddd8f1 [BUG] Use arith_uint256 for old modifier's block sorting (random-zebra)
b1c0afb [Trivial] Log stake modifier and timeBlockFrom in CheckKernelHash() (random-zebra)
ddf0dcb [arith_uint256] Do not destroy *this content if passed-in operator may reference it (Karl-Johan Alm)
8fe19b1 [Refactor] uint256 add missing explicit instantiation for base_blob<512> (random-zebra)
22213ff [Refactor] Migrate uint256.h/.cpp to blob_uint implementation (random-zebra)
957f529 [Refactor] pow/pos: use arith_uint256 for difficulty targets (random-zebra)
9663d99 [Refactoring] GUI/RPC: use uint256S() to construct uint256 from string (random-zebra)
b02a67b [Refactor] Use arith_uint256 for masternode ranking computations (random-zebra)
990072e [Refactor] Move trim256 and use arith_uint512 for HashQuark calculations (random-zebra)
f8c41ca [Refactor] zerocoin: use arith_uint256 where needed (random-zebra)
bce0583 [Refactor] zc ParamGeneration: pass big args by ref and use arith_uint (random-zebra)
6488f24 [Tests] Fix arith in pedersen_hash_/skiplist_/pmt_/transaction_tests (random-zebra)
86e177b [Tests] Replace uint256 tests with blob_uint256 tests (random-zebra)
b4a459b [Refactoring] BIP38: init uint from string and use arith where needed (random-zebra)

Pull request description:

  Finally out of an old rabbit hole, started with #1395, #1414, and #2092.
  As per title, complete the migration:
  - use `arith_uint*` classes whenever the uint is interpreted as a number
  - make `uint*` classes child of `base_blob`, and use it everywhere else
  - remove `blob_uint*` temporary class
  - update tests

ACKs for top commit:
  furszy:
    Have been running this since the last rebase and all good, ACK 722759d
  Fuzzbawls:
    ACK 722759d

Tree-SHA512: cf593243c2f2dbba1a7534cacb7ed261518b4969498dfc703ea875faf87ad94a3ee25eb587aebda225d8617a94301bff5017bb7f00b04d91e0f3e3fbbd04e0f3