Common shared internals

[pyricau]

Just dumping some raw notes about the future architecture:

A thing you can call to trigger a heap dump + analysis That thing is a simple interface which takes a Trigger reason, typed. Maybe it's an Any? Maybe marker interface. This will make it possible to tag, but also skip conditions by wrapping them in a "force" condition.

There's a condition that returns Yes or Nope with a reason.

In tests the trigger will likely be "DetectLeaksAssert" and we'd skip any other request.

DetectLeaksInterceptor looks very much like the conditions we want.

Also somewhat similar to leakcanary.internal.HeapDumpControl.iCanHasHeap However there the reason is a lazy string, and we have NotifyingNope which triggers notifications. So we need a way to have silent canceling and noisy canceling.

Thing is, in the general leakcanary case we don't always need the string reason.

Then we trigger. We also need to pull a directory id. That requires doing additional prework like saving android ids, storing the dump timestamp.

Getting a file might fail. Dumping might fail.

There's some notion of parallel threads and multiple jobs here. Every time we get a request to trigger, we should store that, and make it possible for anyone to cancel that request / all requests at any time. Maybe the request has a stage? but maybe not because we want decoupling.

heap dump directory: releases want to have some control over the file itself and delete it immediately. also wants to run GC. but not check for retained.

After the heap is dumped, we migth want to analyze it, and even double analyze. Might want to send it to another process. etc.

We're essentially sending a file to the thing.