WIP: Add merge-prs.sh script to contrib/

[apoelstra]

TODO

• check whether we're running from /tmp and don't output the "bail out" warning
• check for chronic and any other tools we might need
• use ccache rather than skipping autogen/configure (and configure in multiple ways?)
• don't require running from the project root
• check for required remotes, required branches, etc; notice if merged-master is out of date
• notice if there are uncommitted changes and refuse to run
• add "dry run" mode
• add mode to validate others' commits, including noticing skipped PRs

[apoelstra]

Another thing we should deal with is that the functional tests sometimes fail due to resource contention (typically this looks like errors of the form assert self.rpc_connected and self.rpc is not None, self._node_msg("Error: no RPC connection") in the Python backtrace, which fortunately is easy to match on). We should notice this and retry.

[apoelstra]

I realize that the RPC errors only happen when I mess with my network interfaces while the tests are running. Probably I should just not do that.

[apoelstra]

More missing features

• Give user control over all the -jXX choices
• Don't sort the PRs; let user decide whether to take Elements PRs or Bitcoin PRs

[apoelstra]

@gwillen do you remember what the point of all this "copy to /tmp" complexity was?

[gwillen]

@gwillen do you remember what the point of all this "copy to /tmp" complexity was?

Because otherwise, when the script starts checking out branches / merging things / etc., it is liable to check itself out of existence, if you are running it from inside the same repo it's operating on. (Or check itself out to the wrong version, or...)

[apoelstra]

It won't check itself out of existence, because it only checks things out via git merge ... which will only delete files if those files were deleted in whatever we're merging.

It may update itself, yes, but this is probably expected and good. We could add some code that would detect changes (much easier to do than /tmp shenanigans) and to advise the user to restart the script whenever this happens.

But regardless I think this will be very rare.

[delta1]

I think this was superseded by #1210, will create an issue from the TODOs and at some point evaluate what still needs to be done