ir: add BIP152 getblocktxn/getdata(cmpctblock) generators + probe feedback loop

[brunoerg]

Add GetCompactBlockGenerator and GetBlockTxnGenerator so the IR can drive the pull side of compact block relay: request a compact block via getdata(MSG_CMPCT_BLOCK) for a block the node announced, and follow up with a getblocktxn for a cmpctblock the node sent us.

Neither flow can be synthesized in a single program (a getblocktxn is only meaningful after the node itself sends a cmpctblock, which the IR cannot fabricate). Instead, extend the probe mechanism to record headers/inv and cmpctblock messages, decode them into BlockAnnouncement/ CompactBlockAnnouncement metadata, and let generators insert the matching follow-up request right after the instruction that triggered the announcement on a later mutation pass.

Refactor bin/ir.rs into fuzzamoto-scenarios/src/lib.rs as a generic IrScenario<TX, T, const CMPCT: bool> so the existing scenario and the new compact-block variant (scenario-ir-cmpctblock, bin/ir_cmpctblock.rs) share one implementation, differing only in which messages get recorded/drained (is there a better way to do it? I ended up creating this lib.rs to avoid duplicating code).

[dergoegge]

Neither flow can be synthesized in a single program (a getblocktxn is only meaningful after the node itself sends a cmpctblock, which the IR cannot fabricate). Instead, extend the probe mechanism to record headers/inv and cmpctblock messages, decode them into BlockAnnouncement/ CompactBlockAnnouncement metadata, and let generators insert the matching follow-up request right after the instruction that triggered the announcement on a later mutation pass.

Any block a node announces will have been generated by the IR, so I'm not sure if we need to split into two separate scenarios. If the scenario receives an inv or cmpctblock etc., the probing should result in testcase metadata, that tells a generator/mutator details about what mutations would be useful (similar to how the probing for blocktxn already works).

[brunoerg]

Any block a node announces will have been generated by the IR, so I'm not sure if we need to split into two separate scenarios. If the scenario receives an inv or cmpctblock etc., the probing should result in testcase metadata, that tells a generator/mutator details about what mutations would be useful (similar to how the probing for blocktxn already works).

I was in doubt about this part, will see it better.

[brunoerg]

Thanks, @dergoegge. I've changed it back to be just one scenario with an identical approach of the probing for blocktxn. I will leave it running overnight and generate a coverage report.