Investigate opportunities to speed-up invariant_booleans.

[pq]

Looking at the benchmarking bot, invariant_booleans is running considerably longer than other lints.

---------------------------------------------------
Timings                                          ms
---------------------------------------------------
public_member_api_docs                          157
invariant_booleans                              154
close_sinks                                      46
unnecessary_this                                 46

I wonder if there are any remaining opportunities for speed-up?

cc @alexeieleusis

FYI @bwilkerson

[alexeieleusis]

Back when I started contributing lints I thought about this one because I saw it was the one with more violations in several few big projects like the jdk and some big open source codebases. The experience with the Dart SDK was quite different with very few occurrences and few false positives, within my project there have been only false positives (surprisingly not easy to reproduce). Additionally most of the cases where this verification would be valuable are catched by literal_only_boolean_expression since the errors themselves seem to be "debugging leftovers". Apparently code review catches all of them.

All of this to say that probably this lint should be deprecated or at the very least make is clear that running it in CI (or similar) cycles should be enough to get the value it provides, for instance, in my team we have it disabled for IDE inspection.

I will look into it, but it has previously gone through a couple of cycles like this, so I am not very optimistic we can get much out of it.

[pq]

FWIW, this one has crept to the top of the "slow lint" list.

Not sure if we want to deprecate (and should really track usage) but we should probably tag as slow (once we have support for tags -- #57719).

[srawlins]

We've deprecated invariant_booleans and will not be fixing correctness bugs going forward.