feat(eslint-plugin): [no-unnece-cond] Add allowConstantLoopConditions

[a-tarasyuk]

Fixes #1015

[typescript-eslint]

Thanks for the PR, @a-tarasyuk!

typescript-eslint is a 100% community driven project, and we are incredibly grateful that you are contributing to that community.

The core maintainers work on this in their personal time, so please understand that it may not be possible for them to review your work immediately.

Thanks again!

---

🙏 Please, if you or your company is finding typescript-eslint valuable, help us sustain the project by sponsoring it transparently on https://opencollective.com/typescript-eslint. As a thank you, your profile/company logo will be added to our main README which receives thousands of unique visitors per day.

[codecov]

Codecov Report

Merging #1029 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #1029      +/-   ##
==========================================
+ Coverage   94.23%   94.24%   +<.01%     
==========================================
  Files         126      126              
  Lines        5377     5384       +7     
  Branches     1510     1513       +3     
==========================================
+ Hits         5067     5074       +7     
  Misses        177      177              
  Partials      133      133

Impacted Files	Coverage Δ
...slint-plugin/src/rules/no-unnecessary-condition.ts	100% <100%> (ø)	⬆️

[bradzacher]

I haven't reviewed the code yet - but I think I'd rather it if the option was named "allowConstantLoopConditions". To me "checkLoops" implies that you're turning off checks for loops entirely.

[Retsam]

Do we need to have this behavior behind an option? I know it's consistent with no-constant-condition to put this behavior behind and option, but it almost seems unnecessary. If someone's writing while(true) it seems pretty clear that it's intentional and not an unnecessary condition.

Certainly, some people would like a linter error on that line, because they want the linter to forbid infinite loops; but that seems like a stylistic preference that's a bit tangential to the purpose of this rule. (Which is intended to be a correctness rule, more than stylistic) Maybe forbidding infinite loops should be the purview of some other rule - maybe a rule specific to that purpose.

[bradzacher]

Do we need to have this behavior behind an option

Enhancements need to be backward compatible.
Removing the check is a breaking change, so it needs to be behind a default false option, or else this PR will have to wait for the 3.0 release.

[bradzacher]

code and test mostly LGTM.
one comment to address and then we can merge this in.

[bradzacher]

LGTM - thanks for this!