Last phase of OOM refactoring.

[kstenerud]

• Replaced BSGOutOfMemoryWatchdog with BugsnagSystemState.
• Moved OOM detection into BugsnagClient, which uses BugsnagSystemState as its information source.
• Stronger and more explicit OOM heuristics.
• OOM detection now relies entirely upon last launch state (includng debugger status).

Under the new system, you can cause an out of memory shutdown while the app is not being debugged, and then launch it in a debugger to observe it sending an OOM event (bringing the OOM behaviour in-line with the other events). Any sudden shutdowns while a debugger is active won't generate an OOM event (same as before).

OOMs are now enabled by default on DEBUG builds (like on RELEASE builds). We don't need this distinction anymore since the library records whether it was being debugged or not.

We should still add more heuristics later. All heuristics are contained and explained in a single easy-to-follow method "didLikelyOOM" in BugsnagClient.

Testing

Testing was done using the app's OOM test, as well as using Xcode to simulate sudden shutdowns in various situations (simulating the sudden shutdowns that the OOM handler looks for in its heuristics).

All testing was performed in release mode.

Testing debugger detection:

To test debugger detection, I turned the debugger on/off while triggering a sudden termination in between.

Debugger	OOM?
ON, ON	No
ON, OFF	No
OFF, OFF	Yes
OFF, ON	Yes

Other testing:

These were run with no debugger in order to verify the behaviour in various situations.

Test	OOM?
Run OOM test in example app	Yes
Background, then terminate app	No
Shutdown app normally	No
Launch, terminate, change version, launch	No
Launch, terminate, launch	Yes

[nickdowell]

Should we move this method into BugsnagSystemState?

It would help reduce the size of BugsnagClient a bit, and the method doesn't access anything in the client.

[kstenerud]

I'm trying to keep BugsnagSystemState's purpose to only recording information rather than interpreting it.

Of course, BugsnagClient isn't really the ideal place to interpret it either I suppose...

[kstenerud]

Update: I've had to add special "purge" methods to allow resetting persistent state since many of the tests make assumptions about the state at the start of the test. I suspect that many tests are actually wrong in their assumptions, but work because they happen to run in a particular order. We'll need to decide how we want to ensure a deterministic start state in our tests at some point, because otherwise this will keep biting us.

I've also had to modify one of the stack trace interpretation tests because something on my computer is now producing slightly different data for the same test.

[kattrali]

looks good, raised one nit about the changelog