Consider adding a diff cargo mutants CI workflow

[benalleng]

rust-bitcoin only utilizes a weekly cargo mutants workflow at the moment but after adding a diff mutants CI to our workflow with --in-diff and finding it valuable I wanted to bring it to y'alls attention in case you hadn't yet considered it fully as I can only see a brief mention of it in this comment #2829 (comment).

Based on how the diff mutations work the weekly mutations would likely stay as changes to tests etc would not be caught as only source code changes can be tested. This would simply allow most mutations to be caught more quickly in the PR -> merged pipeline as an example the mutants in #5088 via #5030 could be safely ignored before merging.

Below is how we do it in rust-payjoin
https://github.com/payjoin/rust-payjoin/blob/b97ffb7129aceea4bb56ec7789681d56423572b6/.github/workflows/rust.yml#L126-L158

[apoelstra]

Yeah, this is a pretty good idea (now that we've gotten the mutant count down to near-zero).

[benalleng]

A few questions popped up while implementing this.

• Should there be a custom --timeout/--test-timeout flag set to prevent large diffs from holding up the CI
• Do reviewers want a temp DO NOT MERGE commit to see a realistic dry-run of the new CI before merging

[apoelstra]

• Should there be a custom --timeout/--test-timeout flag set to prevent large diffs from holding up the CI

Nah, I think it's fine. We'll remember that we can do this in case it becomes a problem in the future.

• Do reviewers want a temp DO NOT MERGE commit to see a realistic dry-run of the new CI before merging

I also think it's fine :P. Historically we usually just merge CI changes and then do a bunch of iteration until it looks right. I don't think we've ever successfully done a "dry run" because none of us know Github's rules for when to run what on what.