utils/transaction: handle insert_source errors gracefully

[bsdlme]

Instead of unwrap()ing the calloop insert_source calls in
register_deadline_timer, handle errors explicitly. If the ping
source registration fails after the timer was already inserted,
roll back by removing the timer to avoid a source leak.

This fixes a panic seen on FreeBSD where fd number reuse causes
the second insert_source call to return IoError(AlreadyExists),
crashing the compositor session.

[YaLTeR]

This fixes a panic seen on FreeBSD where fd number reuse causes
the second insert_source call to return IoError(AlreadyExists),
crashing the compositor session.

How can this happen? Is there a leak somewhere?

[bsdlme]

Note: This patch was generated using Claude AI. I don't know if it is the correct way to fix the problem but with the patch applied, Niri no longer crashes when I run pkill waybar && waybar.

The Stacktrace was:

thread 'main' (103510) panicked at src/utils/transaction.rs:119:18:
called `Result::unwrap()` on an `Err` value: IoError(Kind(AlreadyExists))
stack backtrace:
   0:     0x11ca49acf98a - <<std[80f920bd99e0aebc]::sys::backtrace::BacktraceLock>::print::DisplayBacktrace as core[c71261b22e85d8da]::fmt::Display>::fmt
   1:     0x11ca4907e02a - core[c71261b22e85d8da]::fmt::write
   2:     0x11ca49acec55 - <std[80f920bd99e0aebc]::sys::stdio::unix::Stderr as std[80f920bd99e0aebc]::io::Write>::write_fmt
   3:     0x11ca49ace9cc - std[80f920bd99e0aebc]::panicking::panic_with_hook
   4:     0x11ca49af6417 - std[80f920bd99e0aebc]::panicking::panic_handler::{closure#0}
   5:     0x11ca49af63c9 - std[80f920bd99e0aebc]::sys::backtrace::__rust_end_short_backtrace::<std[80f920bd99e0aebc]::panicking::panic_handler::{closure#0}, !>
   6:     0x11ca49af68cc - __rustc[d8ff9d08a1174409]::rust_begin_unwind
   7:     0x11ca4907debb - core[c71261b22e85d8da]::panicking::panic_fmt
   8:     0x11ca49083971 - core[c71261b22e85d8da]::result::unwrap_failed
   9:     0x11ca49646a80 - niri::utils::transaction::Transaction::register_deadline_timer::hdb25d4a93688a756
  10:     0x11ca49656d09 - smithay::wayland::compositor::add_pre_commit_hook::{{closure}}::h9de19be46d1e21ee
  11:     0x11ca4967bcf0 - <wayland_server::dispatch::ResourceData<I,U> as wayland_backend::sys::server::ObjectData<D>>::request::h99a62923c644aa21
  12:     0x11ca49395915 - wayland_backend::sys::server_impl::resource_dispatcher::h1ce3a77fd03aff41
  13:     0x11d26c05add6 - <unknown>
  14:     0x11d26c05495e - <unknown>
  15:     0x11d26c05876f - wl_event_loop_dispatch
  16:     0x11ca4950f50f - <core::cell::RefCell<calloop::sources::DispatcherInner<S,F>> as calloop::sources::EventDispatcher<Data>>::process_events::h0aef6239bb3c1217
  17:     0x11ca48efbdc7 - niri::main::hfd6e52145396471d

[YaLTeR]

Yea I dunno about this. Sure we can add a check to avoid the panic, but I would like someone to get to the bottom of it and fix it at the right place

[bsdlme]

I am open for any suggestion how to best handle this. If you need me to try something, just ask. :-)