Device memory instrumentation

[Doohl]

Issue

To help customers correlate screen load increases (ie TimeToFirstDraw) to device / hardware issues, we should author instrumentation that can monitor on low memory events. Ideally, we should contribute this instrumentation upstream.

Related upstream issue: open-telemetry/opentelemetry-android#283

[Doohl]

One way we can do this is with the ComponentCallbacks2.onTrimMemory(int) method. This allows us to monitor on a few types of events:

1. TRIM_MEMORY_RUNNING_MODERATE -- the process is not an expendable background process, but the device is running moderately low on memory.
2. TRIM_MEMORY_RUNNING_LOW -- the process is not an expendable background process, but the device is running low on memory.
3. TRIM_MEMORY_RUNNING_CRITICAL -- the process is not an expendable background process, but the device is running extremely low on memory and is about to not be able to keep any background processes running

This has one glaring limitation: apps are no longer notified of these memory signals as of API level 34 and beyond.

Thus, for distributions >= level 34, we will need to use the Memory Advice API, which is currently in Beta. The Memory Advice API gives us a few signals:

1. MEMORYADVICE_STATE_OK
2. MEMORYADVICE_STATE_APPROACHING_LIMIT
3. MEMORYADVICE_STATE_CRITICAL

Telemetry to vend

Proposal is to vend two new types of Events (not Spans):

1. memory.running_low that maps to TRIM_MEMORY_RUNNING_LOW and MEMORYADVICE_STATE_APPROACHING_LIMIT (API 34+)
2. memory.running_critical that maps to TRIM_MEMORY_RUNNING_CRITICAL and MEMORYADVICE_STATE_CRITICAL (API 34+)