Guard against exceptions in to_s when cleaning objects

[imjoehaines]

Goal

When sending notifications we run through a "cleaning" stage which does things like filter out any keys that we shouldn't send in the error report (e.g. passwords). This calls to_s in a couple of different places, which can cause issues as objects are free to implement any logic and can therefore throw exceptions or infinitely recurse, which means we end up crashing while trying to cleanup the object

In this PR we'll now recover from exceptions and stack overflows by replacing the values with one of our existing replacement strings:

1. [RECURSION] if we get a SystemStackError when stringifying a plain object
2. [FILTERED] if we get an exception when attempting to filter keys in a hash map — if an exception happens we can't tell if we should filter the key, so we have to assume we need to

This means the error report will have less information that intended, but this should be rare and if it does happen then the alternative is no report at all

Changeset

Changed

• Rescue SystemStackError as well as other exceptions when calling to_s on an object
• Rescue StandardError and SystemStackError when calling to_s on a key when filtering a hash map

Tests

Tests have been added for:

• hash keys that throw during to_s
• hash values that throw during to_s
• custom objects that infinitely recurse during to_s

Discussion

Alternative Approaches

Outstanding Questions

Linked issues

Related to #577

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