bug(dev): Core dump when panic

[cchudant]

Is there an existing issue?

• I have searched the existing issues

Description of bug

When the node shuts down because of a panic, the node is supposed to stop gracefully
However, when I add a todo!() at a random place in the code, this happens:

[2024-09-13 10:49:15 HTTP] 🌐 starknet_V0_7_1_call 200 102 bytes - 83.436ms
[2024-09-13 10:49:16 HTTP] 🌐 starknet_V0_7_1_getClass 28 77 bytes - 293µs
[2024-09-13 10:49:16 HTTP] 🌐 starknet_V0_7_1_getNonce 200 39 bytes - 363µs
[2024-09-13 10:49:16 HTTP] 🌐 starknet_V0_7_1_getNonce 200 39 bytes - 368µs
thread 'tokio-runtime-worker' panicked at crates/client/rpc/src/providers/mempool.rs:40:54:
not yet implemented
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
run.sh: line 39: 51977 Aborted                 (core dumped) ./target/debug/madara --gateway-key <hidden> --base-path .deoxysdb --no-l1-sync $@

The process is aborted and the core is dumped. I wonder what's happening, but the rocksdb "gracefully closing the db" log is not shown - it might be related..? weird
We do not use unsafe anywhere in the codebase, so I'm guessing this is probably the Drop implementation of rocksdb::DB doing this. (for those who don't know, the DB graceful close is implemented using the Drop trait, because unwinding the stack runs destructors :) )

This is lower priority as we're not supposed to panic anyway, but in case we panic we're supposed to close the db properly. Also, we are already fault-tolerant, so not closing the db properly is not that big of a deal.

Steps to reproduce

No response

[cchudant]

For any contributor wanting to take this: the way you would debug this kind of thing is using gdb or lldb, and opening the core dump (that's what it's for ;) )