More robust or flexible semver break checks

[nyonson]

@apoelstra pointed out in #43 (comment) that the api command will probably be a little too trigger happy with false positives. api currently looks for breaks at a syntax level, but there are some interesting corner cases where syntax changes but semantics do not. As in, the Rust type checker is still happy so it is not a breaking change.

There are 2 checks performed by the api command, additive and semver. Additive is between feature flags, while semver is between package versions. While the false positives are possible in both, they are more painful for the additive checks because they are re-surfaced on every change. Whereas the semver ones, for better or worse, show up once for a change and that is it. So a maintainer could OK a patch with a comment on how it is a false positive.

One solution is to switch to using the cargo-semver-checks crate for semver breaks. This is what the existing script in rust-bitcoin is using, and cargo-semver-checks publishes a library crate which we could use under the hood in rbmt. However, and this may be due to my naivety of the domain, the dependencies required look massive for the task. For example, bleeding edge MSRV (only two weeks old) and a whole rust native git library. This is a big step jump for cargo-rbmt which is really just meant to be a simple cargo orchestrator.

I am wondering if a whitelist approach can be taken with public-api instead, where known corner cases are OK'd once for a package and added to the rbmt.toml config.

[apoelstra]

I wonder if we should xshell out to cargo semver-checks itself. It's obviously not as elegant as linking into the library but it "isolates" the massive dep tree and MSRV requirement from our own lockfiles and codebase.

I'm skeptical that any solution that tries to use public-api, even with whitelisting, will work.

We could try to beg @obi1kenobi to reduce the dependency tree, but like, ultimately all these huge deps are actually used for functionality. So I don't think it's possible to get it down to something where we could bundle it directly into cargo-rbmt without 10xing our dependency tree.

If the xshell solution becomes too ugly to maintain we can just bite the bullet. I don't particularly mind having a bleeding-edge MSRV and a big dep tree here since it's just a development tool, but it does have a logistical cost to keep up with all this..

[obi1kenobi]

I'd also recommend shelling out to cargo-semver-checks over using it as a library. I'm a bit slammed with work at the moment, but time & funding permitting in principle we could look into having a stable ("additive changes only") machine-readable output to make c-s-c data easier to consume.

Also FWIW you can also use cargo-semver-checks to ensure features are additive. It just requires a small trick: have it check the same code with different features enabled between the baseline and the current arm of the check. To check that a feature X is additive when features A and B are active, have the baseline have only A + B, and have "current" have A + B + X active. If adding X is non-additive, it'll get detected as a breaking change. Since you know the underlying code is the same (e.g. same path, or same git revision) and the only difference is features, X must be a non-additive feature in the flagged aspects.

Lmk if the features trick makes sense. If needed I can come up with a concrete example with a CLI invocation to demonstrate it.