Extend CI with builds for main downstream dependencies

[dr-orlovsky]

To avoid the problems like we have with each release breaking downstream (the most recent one was #608) I propose to simplify the detection of whether the change is API- or runtime-functionality-breaking by extending the current CI with running builds for main projects using rust-bitcoin downstream. CI script should clone the project git repo, apply a patch to its Cargo.toml and compile it.

The proposed list of projects to run the tests:

• rust-lightning
• miniscript
• BDK
• descriptor wallet
• electrs (both original & esplora fork)

[sgeisler]

We should probably make this part of our release process for minor releases. But as part of CI it would expectedly fail whenever we are planning to do a major release, so idk if that would be useful.

[RCasatta]

@dr-orlovsky I thought the same thing...

apply a patch to its Cargo.toml and compile it.

test it instead of compile it, otherwise latest bug, the character for the hardened derivation, isn't get caught

We should probably make this part of our release process for minor releases. But as part of CI it would expectedly fail whenever we are planning to do a major release, so idk if that would be useful.

we can have specific jobs for this not requiring successful ending
https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#jobsjob_idstepscontinue-on-error

and not required for the mergeability see "status checks" at https://docs.github.com/en/github/administering-a-repository/defining-the-mergeability-of-pull-requests/managing-a-branch-protection-rule#about-branch-protection-rules

[apoelstra]

Yeah I think it's reasonable to have these but to make them non-required for merging. They'd still be noticeable and should rarely fail.