Add config.logtail.enabled to turn the integration off per environment

[PetrHeinz]

There is no way to turn the Rails integration off in one environment. Installing the gem is enough to change local logging: the gem silences DebugExceptions' own logging, so development logs lose exception backtraces; log/development.log stops being written once config/application.rb sets config.logger = Logtail::Logger.create_default_logger(...) as the docs show; and when the logger is only configured for production, the default Rails logger prints raw Ruby hashes. The red-team reproduced all three on Rails 8.1, e.g. with the docs setup in development a failing request logged only ArgumentError (issue10 boom), without a backtrace, and no log/development.log was written. Reported in #10

This adds config.logtail.enabled, true by default:

• Logtail::Config#enabled= and #enabled? in lib/logtail-rails/config.rb, reachable as config.logtail.enabled in config/application.rb and config/environments/*.rb.
• A new :logtail_enabled initializer runs after the environment files are loaded and before Rails' :initialize_logger. When the switch is off, it calls Logtail::Integrations::Rails.enabled = false before the :logtail initializer builds its middleware list, so no Logtail middleware is installed, DebugExceptions, Rails::Rack::Logger and the log subscribers stay unpatched, and the Rails.event subscriber stays disabled.
• If config.logger holds a Logtail::Logger at that point, typically the one create_default_logger built in config/application.rb, it's replaced by a Logtail::Logger that writes to log/<env>.log. Calls like Rails.logger.info("message", key: value) keep working, nothing goes to Better Stack, and rails server still mirrors the log to the console.
• One README line.

Behaviour and compatibility:

• Nothing changes unless an app sets the switch to false.
• It has to be set in config/application.rb or an environment file. config/initializers/* run after Rails has set up its logger, which is too late.
• Any Logtail::Logger in config.logger is replaced, not only one built by create_default_logger, since a disabled environment shouldn't send logs.
• In a Sidekiq server process, Sidekiq.logger keeps the logger that create_default_logger gave it. This PR doesn't change that.

The tests boot a small app in a subprocess per case, because booting patches Rails classes for the whole process: switched off in development (where create_default_logger builds the HTTP logger) and in test (where it returns the STDOUT logger), plus a control boot with the default.

Targets the 0.2.15 patch release. No dependencies.

The commit "Expect real response durations in the request specs" is the same change as in #59: logtail-rack 0.2.8 times responses with the monotonic clock, which Timecop doesn't freeze, so three existing specs now fail on every branch based on main. It's identical in both PRs, so it merges cleanly whichever lands first.

The first commit only adds the tests and is expected to fail on CI. The implementation follows in the next commit.

Follow-up (f2e1f30 test, 0cb8ae6 fix): with the switch off, the log file used to start with Ruby Logger's # Logfile created on … by logger.rb line. That happened because the path was passed to Logger, which then created the file. Rails opens log/<env>.log itself, so stock Rails has no such line. The file is now opened the same way. I ran the same app side by side, once without the gem and once with config.logtail.enabled = false: log/development.log, log/test.log and the console output were identical apart from timings.

🤖 Generated with Claude Code