tests: Add fuzzing harness for CheckBlock(...) and other CBlock related functions

[practicalswift]

Add fuzzing harness for CheckBlock(...) and other CBlock related functions.

Testing this PR

Run:

$ CC=clang CXX=clang++ ./configure --enable-fuzz --with-sanitizers=address,fuzzer,undefined
$ make
$ src/test/fuzz/block
…
# And to to quickly verify that the relevant code regions are triggered, that the
# fuzzing throughput seems reasonable, etc.
$ contrib/devtools/test_fuzzing_harnesses.sh '^block$'

test_fuzzing_harnesses.sh can be found in PR #17000.

[maflcko]

Concept ACK

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• #17229 (tests: Add fuzzing harnesses for various Base{32,58,64} and hex related functions by practicalswift)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

[practicalswift]

Rebased! :)

[practicalswift]

Rebased and added a fuzzing harness for ContextualCheckBlock(…).

[practicalswift]

@MarcoFalke

When fuzzing BlockWitnessMerkleRoot(…) I noticed that leaves[0].SetNull() is done also in the case when leaves.empty() (due to block.vtx.empty()):

bitcoin/src/consensus/merkle.cpp

Lines 75 to 84 in d0f81a9

	uint256 BlockWitnessMerkleRoot(const CBlock& block, bool* mutated)
	{
	std::vector<uint256> leaves;
	leaves.resize(block.vtx.size());
	leaves[0].SetNull(); // The witness hash of the coinbase is 0.
	for (size_t s = 1; s < block.vtx.size(); s++) {
	leaves[s] = block.vtx[s]->GetWitnessHash();
	}
	return ComputeMerkleRoot(std::move(leaves), mutated);
	}

Makes sense to guard against this? :)

Update: Working around this by simply skipping the call to BlockWitnessMerkleRoot(…) in case of block.vtx.empty().

[practicalswift]

Rebased! :)

[practicalswift]

Should be ready for final review :)

[maflcko]

ACK c5d08da