Read projectPackages array when serialising error reports

[fractalwrench]

Goal

It is currently possible to call Bugsnag.setProjectPackages after bugsnag has been initialsed, although for nearly all conceivable usecases this value won't change in the lifetime of an application. For example:

Bugsnag.init(this) // uses the default project packages, and starts flushing error reports
Bugsnag.setProjectPackages("com.myexample") // sets value AFTER report is sent

The Bugsnag and Client accessors have been deprecated in favour of setting this value on the Configuration object, and passing that in as a constructor parameter to the Client. Additionally, the ErrorReader class has been altered so that the correct projectPackages value is now used.

Changeset

• Deprecated projectPackages accessors on Bugsnag and Client in favour of Configuration
• Moved inProject() to Stacktrace as only used there
• Added projectPackages field to Stacktrace that is used for in-project calculations
• Altered test code to reflect new call signatures
• Made ErrorReader serialisation methods generic with casts so caller can use typing properly

Tests

Manually tested

Followed the steps in #418 to confirm that the projectPackages is now correctly set when manually inspecting the payload. Also relied on existing unit tests.

[bengourley]

I didn't test out the implementation – I'd need some guidance to put together steps to reproduce if we want to do that. I read and looked through the code in great detail and have made some remarks on the changes I saw.

I think if we zoom out a bit as well, this seems like an overly complex change in order to fix quite a trivial bug. I do understand that you're working within the constraints of what's already in the codebase so it's not a citique on the implementation, more that I want to widen the discussion a little.

I think a whole load of complexity could be removed if the stackframes were marked as inProject = true|false before being serialised, then you don't have to worry about passing around this configuration option, adding getters/setters in multiple places, serialising and deserialising it, only to do a calculation that could have been done way sooner.

I'm assuming that kind of change would be beyond the scope of this piece of work and would be tackled in a larger re-architecture, but I wanted to get your thoughts on it anyway.

[fractalwrench]

After in-person discussion I believe that adding inProject to the serialization of StackTrace will be of similar complexity to the current implementation's approach. Also using inProject will not work for cached reports, for which we would need to serialise projectPackages again anyway.

As I've addressed the remaining feedback I believe this is ready for re-review.