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: #35

[lucab]

/cc @brson @BusyJay for review

[kennytm]

Perhaps make failpoints as the default feature? Dependencies not wanting failpoints could still opt-out with default-features = false.

Suggested change

	failpoints = []
	default = ["failpoints"]
	failpoints = []

[lucab]

I understand the sentiment behind this suggestion, but unfortunately that will nullify this PR. There is no way for cargo to disable default features across transitive dependencies (by design). It does provide a way to enable them though, via the crate/feature syntax.

This library features should be handled by chaining upward the opt-in switch, and leaving the final decision to the top consumer.

I acknowledge this is a breaking change, but at the same time I do believe failpoints are an instrumentation feature mostly meant for testing/debugging mode (i.e. not normally present in release-mode binary)

[BusyJay]

How about naming it activation?

/cc @brson @siddontang @overvenus PTAL

[BusyJay]

@kennytm Do you have any suggestions?

[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 tikv/rust-prometheus#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.

[overvenus]

I have long wanted this!

[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 #31.

[BusyJay]

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