Record storagemanager cache behaviour in internal error reports

[fractalwrench]

Goal

Android API 26 introduced setCacheBehaviorGroup, which tells the OS to delete all the files in a given directory if space needs reclaiming. Coupled with setCacheBehaviorTombstone which truncates files to 0, this could explain the volume of minimal error reports reported by some customers.

We should record this information in our internal error diagnostics to debug the issue further.

Tests

Tested against a local artefact on API 23 + 29 which had been altered to always call recordStorageCacheBehavior when notifying.

[fractalwrench]

I've updated the PR to get the tombstone behaviour directly from the bugsnag-errors directory rather than context.cacheDir.

[tomlongridge]

Can we add some automated tests to check the fields are set in the internal error report?

[fractalwrench]

I've updated the mazerunner scenario for an internal error report to check the storagemanager cache values are set, and to more generally validate other fields that we add to BugsnagDiagnostics.

feedback addressed

[kattrali]

Left comments on one scenario, though the commentary (mostly) applies to both.

addressed review points

[fractalwrench]

I have updated the internal_report feature to run 3 scenarios:

• One for verifying reports are sent on API <26
• One for verifying cache tombstone/group behaviour is false by default
• One for verifying cache tombstone/group behaviour is true when enabled

I have also updated the assertion steps as requested.