Use cfg_attr to ignore expensive tests

[mina86]

Rather than using cfg to not compile expensive tests, use cfg_attr
to conditionally mark such tests as ignored. In other words, instead
of writing:

#[cfg(feature = "expensive_tests")]
#[test]
fn test_clear_old_data_too_many_heights() {
    // ...
}

write:

#[test]
#[cfg_attr(not(feature = "expensive_tests"), ignore)]
fn test_clear_old_data_too_many_heights() {
    // ...
}

With this change, expensive tests will always be built which means
that i) any code changes breaking them will be caught by CI (rather
than having to wait for a nightly run) and ii) code used by expensive
tests only is no longer unused when expensive_tests feature is not
enabled (which means fewer #[cfg(feature = "expensive_tests")]
directives sprinkled throughout code).

Since we no longer mark whole modules as compiled only if the feature
is enabled, this change also means that each individual test needs to
be marked individually (rather than being able to mark whole module).
This makes it more obvious which tests are expensive and which aren’t
(since the marking is right at the test definition site) and
simplifies check_nightly.py script.

Issue: #4490

[matklad]

Definitely an improvement!

I have doubts about introducing a proc macro for this, as this seems a too big of a solution for the problem at hand. I personally would strongly prefer open-coding #[cfg_attr(not(feature = "expensive_tests"), ignore)] on every call-site. My arguments for these, none of which is super strong:

• For a contributor, seeing #[cfg_attr(not(feature = "expensive_tests"), ignore)] immediately shows how to actually run the thing, and what's going on in general. In contracts, #[nightly_test] is a rather opaque thing.
• IDEs hate proc-macros. Interestengly, just today rust-analyzer gained an ability to deal with such macros nicely (by ignoring them) feat: Add config to replace specific proc-macros with dummy expanders rust-lang/rust-analyzer#11193, https://rust-analyzer.github.io/thisweek/2022/01/10/changelog-111.html. This still requires manual configuration though.
• When cargo added similar proc-macro decorator for tests, that measurably added to the compile time. Though, in the case of cargo they added it to every test, and not to a small subset, like we are doing here.
• Slippery slope -- proc macros generally tend to make things harder to work with, and adding more simple proc-macros creates incentive for adding more proc macros

Admittedly, none of the arguments is particularly strong, so approving.

[matklad]

One more weak contra argument -- this has to be a non-dev dependency, which feels not quite right.

[mina86]

@matklad, PTAL

[pmnoxx]

LGTM

I agree with @matklad this looks much better with proc macro. I found out that you can't run tests directly inside CLion, due to macros not being handled properly.

[matklad]

LGTM!