[rails] disable eager loading in make_basic_app

[solnic]

This addresses the issue with very slow test suite when running under Ruby 3.1+ and Rails 7.1+

#skip-changelog

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 98.97%. Comparing base (76ede87) to head (e061593).
Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #2434   +/-   ##
=======================================
  Coverage   98.97%   98.97%           
=======================================
  Files         231      231           
  Lines       15094    15094           
=======================================
  Hits        14939    14939           
  Misses        155      155           

Components	Coverage Δ
sentry-ruby	99.14% <ø> (ø)
sentry-rails	98.46% <100.00%> (ø)
sentry-sidekiq	98.67% <ø> (ø)
sentry-resque	96.85% <ø> (ø)
sentry-delayed_job	98.92% <ø> (ø)
sentry-opentelemetry	99.75% <ø> (ø)

Files with missing lines	Coverage Δ
sentry-rails/spec/dummy/test_rails_app/app.rb	100.00% <100.00%> (ø)

[solnic]

@st0012 hey so eager loading makes the suite super slow under rails 7.1+ - do you know why we have it enabled by default? Specs are passing when it's disabled and the test coverage remains the same.

[st0012]

@solnic The idea was to mimic the production app as much as possible, which usually have eager loading enabled. But if it's causing issues and aren't really relied on by particular tests, it's fine to turn it off too 👍

[solnic]

@st0012 oh I see! I think it's a good strategy actually. In fact, I'm a fan of using actual test apps that you run tests against. Even with our setup we don't really mimic a real app setup. In some of my other projects I have test rails apps generated under spec/fixtures/app-{rails_ver} with some common setup handled in the spec_helper.rb. I also found it to be easier to update the test apps to latest versions because I can use regular Rails tools to help me with that. We could maybe consider switching to such a strategy at some point.

[st0012]

I think we can add a few more expensive "end-to-end" tests that way, but I wouldn't ditch the current test suites just yet.
We can probably maintain one fixture app that targets the latest Rails release and use it to test some more complicated features, like profiling and cron monitoring. But for the majority of features, the current test suite still provides lower maintenance cost and faster feedback imo.