server: build Tokio runtime using oxide-tokio-rt

[hawkw]

As described in RFD 579, we are now recommending that the oxide-tokio-rt crate be used to construct the Tokio runtime in all production software that uses Tokio. This crate provides common functions for constructing Tokio runtimes with the recommended configurations.

In particular, it currently does the following:

• On illumos, configures the runtime to emit DTrace probes, using tokio-dtrace.
• Disables Tokio's LIFO slot optimization. This feature is intended to improve message-passing latency, but because tasks in the LIFO slot do not currently participate in work-stealing, it can result in extreme latency spikes in some cases (see omicron#8334 for a worked example).

Thus, this commit changes propolis-server to construct its Tokio runtimes using oxide-tokio-rt so that these common recommended configurations are included. This requires enabling Tokio's unstable features in the workspace.

[pfmooney]

Apply it to standalone as well?

[hawkw]

The Clippy thing seems like a new lint that's unrelated to this change: https://github.com/oxidecomputer/propolis/actions/runs/15913312178/job/44885677202?pr=913#step:5:1947

[hawkw]

I'm gonna go clean up all the Clippy mess in a separate PR.

[hawkw]

We could also consider configuring Clippy to warn on all uses of #[tokio::main] in the repo, as I suggested here. I opted not to do this, since I felt like the remaining uses of #[tokio::main] in xtasks, examples, and propolis-cli, were all basically fine and it didn't feel necessary to add explicit #[expect] attributes for the lint on all of them. If others disagree, I'm happy to add this.

[pfmooney]

We could also consider configuring Clippy to warn on all uses of #[tokio::main] in the repo

Yeah, for the reasons you cited, that seems a bit unsporting.

[hawkw]

We could also consider configuring Clippy to warn on all uses of #[tokio::main] in the repo

Yeah, for the reasons you cited, that seems a bit unsporting.

Yup, the advice to warn on that was really more intended to workspaces like Omicron, which has a ton of smaller production binaries using Tokio, and folks are adding new binaries a lot. In Propolis, I don't think it's as useful, since any new binaries we add will generally just be xtasks/dev tools.