The coredumper library is not sufficient for generating coredumps in all cases

[seanvaleo]

It is now possible for libscope.so to create a core dump in release 1.3 on glibc systems.

The current implementation (coredumper) has some discovered limitations:

• musl is not supported by coredumper
• go is not supported by coredumper
• applications running on ubuntu 22 are not supported by coredumper

On the topic of coredumps, there are a number of other things that may need some consideration in the future:

1. coredumps themselves need some context to be useful. By context, I mean the application itself and dynamic libraries it references. Do we need to have an option to capture all of this information too (for apps running in a container?)
2. we currently don't attempt to transfer coredumps across a network connection, do we need to add this?
3. we've seen coredumps in our java7 integration (debian 8) test take 60s to complete. Otherwise the creation seems to be very responsive. Does this merit further investigation? I'm inclined to think we should wait to see if we observe this anywhere else.
4. Right now in snapshotSignalHandler(), we're delaying 2s before calling the appSignalHandler. And the daemon waits 1s after receiving a signal before trying to grab the output files created by the library. The synchronization between libscope.so and scope daemon should probably be improved. @michalbiesek has shown that if a process joins the same mount namespace as the crashing process, it can access to the any file in that namespace even after all other processes in that namespace have exited. (though there are limitations about searching or viewing directories after the container has stopped). Maybe this could help?