omdb should not crash on SIGPIPE

[davepacheco]

Fixes #8352 in the same way as #5358 fixed oxlog.

[davepacheco]

Reproduced the problem:

root@oxz_switch1:~# omdb nexus blueprints show target | head
note: Nexus URL not specified.  Will pick one from DNS.
note: using DNS server for subnet fd00:1122:3344::/48
note: (if this is not right, use --dns-server to specify an alternate DNS server)
note: using Nexus URL http://[fd00:1122:3344:103::4]:12232
blueprint  bd0318f7-c157-47ef-9d5a-06522379050f
parent:    1c1bf8ba-cfc2-4b69-8ba1-0d715eeb2aff

  sled: 48a4bb91-ae89-4da7-bed9-3bf92111eaab (active, config generation 5)

    host phase 2 contents:
    ------------------------
    slot   boot image source
    ------------------------
    A      current contents 

thread 'main' panicked at library/std/src/io/stdio.rs:1165:9:
failed printing to stdout: Broken pipe (os error 32)
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

root@oxz_switch1:~# mdb -e '::status; $G; $C' core 
debugging core file of omdb (64-bit) from oxz_switch
file: /opt/oxide/omdb/bin/omdb
initial argv: omdb nexus blueprints show target
threading model: native threads
status: process terminated by SIGABRT (Abort), pid=22486 uid=0 code=-1
C++ symbol demangling enabled
fffff8ffffdf01e0 libc.so.1`_lwp_kill+0xa()
fffff8ffffdf0210 libc.so.1`raise+0x22(6)
fffff8ffffdf0260 libc.so.1`abort+0x58()
fffff8ffffdf0270 ~std::sys::pal::unix::abort_internal::hc0fe7b894a48bc67+8()
fffff8ffffdf0280 ~std::process::abort::h9d331ebaa10cbcaa+8()
fffff8ffffdf0290 ~__rustc::__rust_abort+8()
fffff8ffffdf02a0 ~__rustc::__rust_start_panic+8()
fffff8ffffdf0300 __rustc::rust_panic+0xd()
fffff8ffffdf03c0 std::panicking::rust_panic_with_hook::h0aef764ab51e4cad+0x224()
fffff8ffffdf0400 std::panicking::begin_panic_handler::{{closure}}::h95c6fc51d1e834de+0x98()
fffff8ffffdf0410 ~std::sys::backtrace::__rust_end_short_backtrace::h1cf9451894e45d77+8()
fffff8ffffdf0440 ~__rustc::rust_begin_unwind+0x1b()
fffff8ffffdf0470 ~core::panicking::panic_fmt::h3e09b00363b9565a+0x1e()
fffff8ffffdf0500 std::io::stdio::_print::h0bd0d721279921e8+0xcc()
fffff8ffffdf27d0 omdb::nexus::NexusArgs::run_cmd::{{closure}}::h31be7c5b46f3a201+0x450e()
fffff8ffffdf4730 omdb::main_impl::_$u7b$$u7b$closure$u7d$$u7d$::h329a894509d74169 +0x1069()
fffff8ffffdf5c70 tokio::runtime::park::CachedParkThread::block_on::h68829479a9b16282+0xb3()
fffff8ffffdf71c0 tokio::runtime::context::runtime::enter_runtime::h7a192017ac8b0596+0x13d()
fffff8ffffdf86c0 tokio::runtime::runtime::Runtime::block_on::hb1dafbfb46f4c9c9+0x69()
fffff8ffffdf88e0 oxide_tokio_rt::run::h6620662565d1d1aa+0x8b()
fffff8ffffdf9db0 omdb::main::h71dd9560eb66162f+0x1e()
fffff8ffffdf9dc0 std::sys::backtrace::__rust_begin_short_backtrace::h25ebc6d1e4c65419+6()
fffff8ffffdf9e20 std::rt::lang_start::_$u7b$$u7b$closure$u7d$$u7d$::hc66af4ac11719f71 +0x11()
fffff8ffffdf9ec0 std::rt::lang_start_internal::h695ffdb94119632d+0x421()
fffff8ffffdf9ee0 main+0x2c()
fffff8ffffdf9f10 _start_crt+0x87()
fffff8ffffdf9f20 _start+0x18()

Here's the fixed binary:

root@oxz_switch1:~# ./omdb nexus blueprints show target | head
note: Nexus URL not specified.  Will pick one from DNS.
note: using DNS server for subnet fd00:1122:3344::/48
note: (if this is not right, use --dns-server to specify an alternate DNS server)
note: using Nexus URL http://[fd00:1122:3344:103::4]:12232
blueprint  bd0318f7-c157-47ef-9d5a-06522379050f
parent:    1c1bf8ba-cfc2-4b69-8ba1-0d715eeb2aff

  sled: 48a4bb91-ae89-4da7-bed9-3bf92111eaab (active, config generation 5)

    host phase 2 contents:
    ------------------------
    slot   boot image source
    ------------------------
    A      current contents 
root@oxz_switch1:~# 

[sunshowers]

Looks good.

Reasoning for myself: What happens if we were in the middle of a write operation and stdout goes away?

• Today, we'd panic, which would abort, dropping the connection.
• With this change, omdb would receive SIGPIPE and terminate immediately, dropping the connection.

In either case, what happens differs by the service being hit. If it's a Dropshot service, it would be run to completion (we don't cancel futures on connection drop). If it's a database connection, the transaction would be aborted.