Convert frozen middleware error into a warning in the Rails integration

[imjoehaines]

Goal

When running RSpec in a Rails app which has an error in the boot process, Bugsnag will appear to be throwing errors when injecting middleware because the Rails app's middleware stack is frozen (see #534). This isn't actually caused by Bugsnag; the error in the Rails boot process freezes the middleware and when RSpec attempts to run the subsequent files it's never unfrozen. This makes frozen middleware errors inevitable, unless nothing adds middleware, but if we run first then we'll trigger the error. The stacktrace does point out the actual problem, but only in the very first error, which can get buried under the frozen errors that happen for each test file

This comment explains what happens in depth: thoughtbot/factory_bot_rails#303 (comment)

Tests

I've manually tested this catches the frozen error that us trying to inject middleware causes when running RSpec in a broken Rails app. The setup for this is super convoluted and isn't really worth automating — it's possible in a maze runner scenario but you'd need a rails app specifically setup to trigger this and some RSpec tests to run and parse the RSpec output for stack frames with 'bugsnag' in them

Linked issues

Fixes #534

Review

For the submitter, initial self-review:

• Commented on code changes inline explain the reasoning behind the approach
• Reviewed the test cases added for completeness and possible points for discussion
• A changelog entry was added for the goal of this pull request
• Check the scope of the changeset - is everything in the diff required for the pull request?
• This pull request is ready for:
  • Initial review of the intended approach, not yet feature complete
  • Structural review of the classes, functions, and properties modified
  • Final review

For the pull request reviewer(s), this changeset has been reviewed for:

• Consistency across platforms for structures or concepts added or modified
• Consistency between the changeset and the goal stated above
• Internal consistency with the rest of the library - is there any overlap between existing interfaces and any which have been added?
• Usage friction - is the proposed change in usage cumbersome or complicated?
• Performance and complexity - are there any cases of unexpected O(n^3) when iterating, recursing, flat mapping, etc?
• Concurrency concerns - if components are accessed asynchronously, what issues will arise
• Thoroughness of added tests and any missing edge cases
• Idiomatic use of the language

[kattrali]

Cheers for figuring this one out! 🕵️