Send minimal error report if cached file is corrupted/empty

[fractalwrench]

Goal

If a report cannot be delivered due to delivery failure, it is cached on disk. If this cached report cannot be deserialised, or is only partially written, e.g. due to lack of disk space, then currently no bugsnag report will be sent.

This changeset alters bugsnag-android to send a minimal error report for cached JVM exceptions only, by encoding basic error information in the filename.

Changeset

• Updated ErrorStore to pass a Delegate that is invoked whenever a cached file cannot be deserialised
• Implemented Delegate in Client by sending a report with DeliveryStyle.NO_CACHE (this prevents minimal errors from generating other minimal errors if delivery fails and there's a serialisation bug in the notifier)
• Updated Error to include incomplete field that is set when a report is incomplete
• In the previous implementation cached files were only deserialised from JSON if a beforeSend callback was set; files are now always deserialised, which negates the need for Report#errorFile
• Added functions to the ErrorStore which encode and decode basic information about the error from the filename

Tests

• Added a mazerunner scenario for a cached handled and unhandled JVM exception, where the file is either corrupted or entirely empty
• Adapted and added to existing unit test coverage for encoding/decoding of basic error info in the report's filename
• Manually verified that when a cached report is edited on disk and delivered to the dashboard:

[Cawllec]

Maze tests LGTM 👍

[bengourley]

The implementation of this seems a little different than I imagined from our discussions.

I'm confused about the choice to send an "empty" report, rather than sending a report that communicates exactly what happened. I think it will be really confusing for users, with no clue as to why it was there and why it doesn't have any info.

I was imagining something like this:

Attaching any data we have to "Stored Report" (or some other aptly named tab).

Are there any reasons not to pursue this kind of thing?

[fractalwrench]

Note to self: we should probably truncate the error class beyond a certain size to prevent the filename from being too large

[bengourley]

Implementation looks good to me, from reading the code. A few comments that I think will require answers rather than changes.

I'd like to understand how to edit the data on disk so I test out the functionality, unless this is going to UAT?

[fractalwrench]

Thanks for the review! The best way to edit files on an emulator/device would be to set the device into airplane mode so that the crash is definitely stored, then use the Device File Explorer to edit the file before relaunching the app. The file will be stored under `data/data/com.bugsnag.android.example/cache/bugsnag-errors, and you should be able to edit it like a regular file.

I'll have a read through the other comments and address them inline.

[fractalwrench]

I've addressed the remaining comments and also truncated the error class to a max of 40 chars - this is now ready for re-review.