use separate runtime for ldk tasks

[johncantrell97]

An attempt to avoid running into deadlocks when ldk is holding mutexes and we need to block in ldk user land.

Need to test this patch with devrandom's python tests

[praveenperera]

@johncantrell97 in the past I've used once-cell to hold a runtime, might make it easier in this case, to avoid passing the runtime handles around.

use once_cell::sync::{Lazy, OnceCell};

pub static SENSEI_RUNTIME: Lazy<tokio::runtime::Runtime> = Lazy::new(|| {
    tokio::runtime::Builder::new_multi_thread()
         .worker_threads(10)
         .thread_name("sensei")
         .enable_all()
         .build()
         .unwrap();
});

[TheBlueMatt]

I don't believe that this should be required. I'd really like to understand where the issue lies before we fall down this path.

[TheBlueMatt]

Ah, if @devrandom is right at lightningdevkit/rust-lightning#1367 (comment) then I think a much simpler approach would be to just create a single threaded runtime in place in the persister. This would also make it simpler to just revert the changes after lightningdevkit/rust-lightning#1470 . I'm not aware of any other lock issues as there's not much other reentrancy in LDK.

[johncantrell97]

going to close this in favor of the hopefully simpler workaround