Add internal endpoint for tokio task dumps

[joshua-spacetime]

Description of Changes

Introduces another /internal route for capturing tokio task dumps.

The endpoint is available under /internal/task-dump and returns a plain-text dump of every task on the selected Tokio runtime.

Usage Examples

Dump the main runtime

curl -fsS \
  'http://127.0.0.1:3000/internal/task-dump?runtime=main' \
  > task-dump-main.txt

timeout_ms defaults to 2 seconds.

Dump the replication runtime with a longer timeout

curl -fsS \
  'http://127.0.0.1:80/internal/task-dump?runtime=replication&timeout_ms=5000' \
  > task-dump-replication.txt

An unknown runtime returns 400 Bad Request with the valid names. If the runtime cannot complete the dump within the requested timeout, the endpoint returns 504 Gateway Timeout.

API and ABI breaking changes

None

Expected complexity level and risk

2

Testing

• Manual test on supported platform (not macos)

[gefjon]

Works on my machine, except that:

• No replication runtime on standalone.
• Query param for timeout is timeout-ms, not timeout_ms, due to some rewriting somewhere between Axum and serde.
  • EDIT: I was misinterpreting the error from replication being an unknown runtime. timeout_ms does appear to be correct. timeout-ms is ignored as an unknown query param.

But I was able to run several requests and get sensible responses against SpacetimeDB-standalone running locally.