Standardize use of ENV.fetch for strings / numbers

[ksylvest]

Motivation / Background

Usage of ENV.fetch is inconsistent throughout the repo. Given a slight mem / perf optimization this standardizes to use fetch w/ the fetch(key, default) syntax everywhere the default is an integer / string. This also matches the default preferred format in RuboCop per:

https://www.rubydoc.info/gems/rubocop/RuboCop/Cop/Style/RedundantFetchBlock

Checklist

Before submitting the PR make sure the following are checked:

• This Pull Request is related to one change. Changes that are unrelated should be opened in separate PRs.
• Commit message has a detailed description of what changed and why. If this PR fixes a related issue include it in the commit message. Ex: [Fix #issue-number]
• Tests are added or updated if you fix a bug or add a feature.
• CHANGELOG files are updated for the changed libraries if there is a behavior change or additional feature. Minor bug fixes and documentation changes should not be included.

[rafaelfranca]

Thank you for the pull request, but we don't accept cosmetic changes.

[zzak]

Given a slight mem / perf optimization

I can see an argument to change this if there is an actual impact on performance, but I think most of the changes here might only affect startup?

Do you have a benchmark for the before and after?

As we disable all of the rubocop defaults here:

rails/.rubocop.yml

Lines 10 to 13 in 699dfdb

	# RuboCop has a bunch of cops enabled by default. This setting tells RuboCop
	# to ignore them, so only the ones explicitly set in this file are enabled.
	DisabledByDefault: true
	SuggestExtensions: false

I wondered if there would be value in explicitly disabling rules, like this, to avoid similar PRs:

• Enable Style/RedundantFetchBlock and autocorrect-all #47327 (🙈)
• Avoid redundant fetch blocks #46167
• Fix standardrb warnings for generated rails app #42449
• WIP: ENV access clean ups #39765

[ksylvest]

@zzak the delta in performance is likely fairly tiny given the non-repeated execution and my motivation is/was to avoid needing to disable / fix when integrating rubocop on freshly generated apps.

For reference, here's a quick benchmark (required fairly huge sample to see a difference):

require 'benchmark'
N = 5_000_000
Benchmark. bmbm do |benchmark|
  benchmark.report("w/ fallback") { N.times { ENV.fetch('KEY', 'fallback') } }
  benchmark.report("w/ block") { N.times { ENV.fetch('KEY') { 'fallback' } } }
end

                  user     system      total        real
w/ fallback   1.721472   0.018988   1.740460 (  1.800765)
w/ block      2.120957   0.019862   2.140819 (  2.248313)

[zzak]

FWIW, I liked Matthew's idea of adding a linter option to the generator which autofixes any violations when running "rails new" but this is probably not a tiny patch