Improve NDK stack-unwinder data

[lemnik]

Goal

Improve the NDK stack-unwinder availability to symbol data.

Design

Introduced the ability to refresh the cached symbol / maps data in the native stack-unwinder:

• a new bugsnag_refresh_symbol_table function for native code
• a new BugsnagNDK.refreshSymbolTable() as part of the bugsnag-plugin-android-ndk module for Java / Kotlin code using System.loadLibrary after startup
• when the app startup is marked as complete, the native layer will refresh to handle any libraries that were loaded between Bugsnag.start and startup completion (for example in the main activity, or similar)

Testing

Moved the CXXExternalStackElementScenario into the cxx-scenarios-bugsnag project, so that it can use the new API and ensure it behaves as expected.

[bugsnagbot]

Android notifier sizes

Format	Size impact of Bugsnag (kB)	Size impact of Bugsnag when Minified (kB)
APK	1886.17	1643.46
arm64_v8a	663.95	422.28
armeabi_v7a	598.42	356.75
x86	737.66	495.99
x86_64	704.9	467.33

Generated by 🚫 Danger

[jgreen210]

isStarted() isn't thread safe - #1795

[jgreen210]

Even if isStarted() were thread safe, bugsnag could be started straight after isStarted() has returned false so a refresh and therefore symbols could be lost.

[lemnik]

Hi @jgreen210, thanks very much for the input and suggestions. We did consider these edge cases when we implemented
the isStarted method, but felt that given its niche use-case the small risk of stale-reads was acceptable.

It’s unlikely that a false-negative isStarted will lead to “missing symbols” here since the native layer will load the
symbol table during Bugsnag.start. Once the app is marked as "started" the symbol table is refreshed in the background. While there are possible races between these points, there are equally possible races between every dlopen and a native crash. Given the nature of the symbol table and its loading requirements, it is deadlock prone guarantee we will have every possible symbol from every possible library load (we would need to refresh the table during a native crash, which risks deadlock or heap corruption). In most (almost all) Android apps the native libraries are loaded before Bugsnag.start is called, and refreshSymbolTables exists entirely for niche cases where native libraries are loaded late in the app execution (for example when starting an Activity or Service).

While isStarted is lacking any memory barriers in its current state, it is extremely unlikely that
isStarted will cache the null client reference in a normal application. We have experimented with several contrived situations to test this, and even a strong compareAndSet on a completely unrelated variable
is enough to flush the caches and trigger the next load to retrieve the correct value (CPU cores don't have huge
caches after all).

isStarted is intended for situations where you are willing to lose data, otherwise there is no good reason
to use it as your app would be structured such that start is always called before calling other Bugsnag APIs.