The background task subsystem could expose basic telemetry information

I was talking with @davepacheco about our existing metrics, and the idea of publishing some data from the background task subsystem came up. It seems like both valuable information and a reasonably well-understood component. The background task Driver starts a new tokio task for each registered background task:

https://github.com/oxidecomputer/omicron/blob/030adce411fe37c9e2d3c70ee5a6cdbdfd49f3f9/nexus/src/app/background/common.rs#L259-L261

That TaskExec is mostly a wrapper around a tokio select loop:

https://github.com/oxidecomputer/omicron/blob/030adce411fe37c9e2d3c70ee5a6cdbdfd49f3f9/nexus/src/app/background/common.rs#L369-L385

That waits for one of three events:

• An explicit notification
• A timeout
• All of its dependencies having finished

We already store a lot of information about the completion status of these tasks, here:

https://github.com/oxidecomputer/omicron/blob/030adce411fe37c9e2d3c70ee5a6cdbdfd49f3f9/nexus/src/app/background/common.rs#L430

This set of data is a great candidate for publishing to oximeter. We could imagine sending the duration of each task's execution, along with:

• The task name
• The reason it ran (the ActivationReason enum, basically)
• The outcome (success or failure, might be enough, though we do have the "details" as a JSON blob)

Making this easily available through a dashboard and / or omdb would be sweet too.

Start in nexus/src/app/background/common.rs, examining Driver, TaskExec, the tokio select loop, and the completion status data around the referenced lines. Determine how execution duration, task name, ActivationReason, and outcome could be published to oximeter, then clarify whether dashboard or omdb exposure is part of done.