add --seedprogram feature

[brunoerg]

This PR implements the --seedprogram feature which allows an IR program to be executed against the target node before the snapshot is taken, so the fuzzer starts from a richer initial state. I've mostly implemented the idea from #131 (comment).

[Crypt-iQ]

Have not tested yet, plan to run a benchmark. I am not hopeful about the txos here providing a larger mempool even with this patch since there seems to be a fundamental limitation(s) somewhere in how fuzzamoto handles utxos. I expect this patch will do better for growing the block index.

[Crypt-iQ]

Looks good, thanks for doing this. I'm currently benchmarking another PR, so I'll be able to run this after that's done next week.

[Crypt-iQ]

nit: I think these comments (here and below) are a bit verbose and probably unnecessary, just my personal preference though

[Crypt-iQ]

This assumes that the highest header is on the same chain as the block creating the coinbase, which may not always be true. To fix this though, the code would have to track pprev like CBlockIndex* does which could be annoying and probably not worth it just for this feature.

[Crypt-iQ]

I hit a taproot error in the compiler after generating a huge seed program:

fuzzamoto/fuzzamoto-ir/src/compiler.rs

Lines 895 to 906 in b4c4f69

	match &mut txo.scripts.requires_signing {
	Some(SigningRequest::Taproot {
	annex_var: target, ..
	}) => {
	*target = Some(annex_var);
	}
	_ => {
	return Err(CompilerError::MiscError(
	"TaprootTxoUseAnnex requires a taproot script".to_string(),
	));
	}
	}

Pretty sure it's a bug and the same one I've hit before when running on master with compile_in_vm where certain programs with taproot IR operations are invalid. Also I'll note that I had to bump the memory limit in fuzzamoto-cli/src/utils/nyx.rs with huge seed programs.

Was able to test and verify with logging that with a seed file, the bitcoind started with 4 mempool txns.

[Crypt-iQ]

More thoughts:

When running this, I noticed with large seed programs that fuzzamoto would start with higher coverage (~8%) compared to fresh (~2% after the first iterations) and IIRC smaller corpus growth initially (which may be a good thing if my memory isn't failing me). I didn't seriously benchmark this at all, just some observations. Fuzzamoto runs do tend to have corpus bloat after a while so maybe this could counter that bloat; there's just no way that all 100K+ corpus entries are useful.

It might be useful to have a side program that's not merged that can call the generators in a specific order (or write some slightly modified generators) that always produce valid blocks that build on the tip and always produce mempool transactions based on coinbase UTXOs. Like basically remove all of the randomness and invalidity from the current generators so we can easily get 1000+ mempool transactions to test with.