[Fix #10581] Fix a false positive for Style/FetchEnvVar

[koic]

Fixes #10581.

This PR fixes a false positive for Style/FetchEnvVar when comparing with ENV['TERM'].
ENV['DISABLE_DOTENV'] != '1' could be treated the same as the already allowed in used_as_flag? (that is, used as a flag).

---

Before submitting the PR make sure the following are checked:

• The PR relates to only one subject with a clear title and description in grammatically correct, complete sentences.
• Wrote good commit messages.
• Commit message starts with [Fix #issue-number] (if the related issue exists).
• Feature branch is up-to-date with master (if not - rebase it).
• Squashed related commits together.
• Added tests.
• Ran bundle exec rake default. It executes all tests and runs RuboCop on its own code.
• Added an entry (file) to the changelog folder named {change_type}_{change_description}.md if the new code introduces user-observable changes. See changelog entry format for details.

[j-miyake]

I think there can be a case like the below where it isn't a flag use. (Not sure if this is a good example, though).
What do you think?

if ENV['SERVER_ROLE'] == 'mailing'
  # Disable some features that must not be used in 'mailing' role.
else
  # Expect other environment
end

[koic]

Hm, it may be possible to allow comparisons only to compare with commonly used values as flags. e.g. '1', 'true'. Thoughts?

[j-miyake]

Yes, that would be a possible option, or we could suggest these allowable uses.

if ENV['DISABLE_DOTENV'].nil?
  ...
end

unless ENV['DISABLE_DOTENV']
  ...
end

[j-miyake]

But it is obvious that the developer knows how the logic branches by the variable in the condition, so detecting the code like my example as an offense may not make sense. (I mean this PR looks good to me now)

[koic]

it is obvious that the developer knows how the logic branches by the variable in the condition

Yeah, probably so. I'm going to merge this PR. Thank you for your feedback.