Currently, we simply call fassert() in mdb_handle_error(). This eventually calls std::abort(), and lets our signal handler record a stack trace.
Unfortunately, because WiredTiger sets a panic flag on the WT connection, this causes all other threads that happen to call into WiredTiger to immediately return WT_PANIC. These threads will race with the panicking thread for the signal handler. Depending on who wins the race, we can sometimes record a stack trace that isn't useful.

The proposal here is to manually record a stack trace in mdb_handle_error() before calling fassert, thus guaranteeing we get at least one stack trace that shows the actual point of panic.