cargo: add a "failpoints" feature

[lucab]

Breaking: this changes the library behavior, disabling code generation (in macro) by default.

It introduces a failpoints Cargo feature that consumers should only enable where relevant (e.g. in testing environments).

Transitive consumers of this library can enable this feature too, with the special name fail/failpoints (this requires a recent cargo binary).

Closes: https://github.com/pingcap/fail-rs/issues/35

[lucab]

/cc @brson @BusyJay for review

[BusyJay]

You need to update all the CI configuration files to run tests with failpoints feature.

[lucab]

An overall update:

• edited both CI configurations to test with and without the feature
• with regard to naming, I'm following API guidelines and sticking to something obviously related to the crate-name, and non-creative
• with regard to feature enablement, default-features makes it opt-out again so I don't think it's tenable here

A middle-ground solution could be to make this cfg(any(debug_assertions, feature = "failpoints")), so that code is always generated in debug/testing mode (i.e. cargo test), but it's strictly opt-in in release mode (i.e. cargo build --release). I'm not huge a fan of this as it introduces more complexity and troublesome sharp edges (think of cargo test --release, see https://github.com/pingcap/rust-prometheus/pull/246), but at least it wouldn't need changes in most consumers' CI. Another drawback is that it won't be anymore possible to disable for debug builds (i.e. cargo build).

[BusyJay]

I'm OK with overall changes. Well done @lucab! The only thing I concerns about is the feature name, but I don't have strong opinions.

[lucab]

@BusyJay @overvenus thanks for reviewing and merging this! Would you mind a git tag and cargo publish for 0.3.0? That would also close https://github.com/pingcap/fail-rs/issues/31.

[BusyJay]

Yes, I will publish this once #32 is merged. Maybe in 24 hours.