Handle 'nil' being notified

[Cawllec]

• Changes 'nil' to a string: "'nil' was notified as an exception"
• Fixes Bugsnag throwing exception during notification process

[kattrali]

What does the stacktrace look like in this case? It would be good to verify that it is also sensible in a test.

[Cawllec]

I've updated the test to look at the stacktrace as well now.

[Cawllec]

This is waiting for the refactoring change to be merged first #440

[snmaynard]

Why does this depend on the refactoring?

Why was this not done in the Bugsnag Client? We already have a bunch of validation of input in there.

[Cawllec]

To avoid continually adding exceptions to rubocop I thought small refactoring tasks (such as breaking helpers into separate files and moving generate_raw_exceptions into a helper from Report) could be done when appropriate. This can be merged without it, but I'll need to updated .rubo_todo.yml

[snmaynard]

I still have a question about this being done in report rather than in the client.

[Cawllec]

It makes sense to me that the notify function handles whether a notification should be sent, whereas the report class handles the content of the notification. As this falls into the latter category, I put it in the Report.

[snmaynard]

The notify method is the public interface, and so it validates user input - it should be there.

[Cawllec]

I've moved the nil exception changes into the Client, and refactored the configuration checks into a private deliver_notification? method. This negates the need for the refactor PR, which I'll close. I'll put together a plan for a proper refactoring that will hit more than a couple of points which can be discussed at a later date.