devel/jobwatch: report unit job transitions per tick

[Alistair-Afton]

Adds a devel/ monitor that polls unit.job.current_job for all active
units once per tick and prints a console line whenever a unit gains,
loses, or switches jobs — including switches between two jobs of the same
type, which is how claim races appear.

Useful when investigating job churn: the assignment pass runs entirely
inside the tick, so from Lua only its effects on current_job are
observable. Complements the external heap sampler in
DFHack/df_misc#90 (which sees the bids; this sees the outcomes).

Commands: start/stop (or enable/disable), unit <id>|all to
filter, verbose to also print job id, posting index, and
do_now/special flags.

Verified live on 53.16: snapshot diffing showed dozens of transitions
tracked correctly over a ~25s window (e.g. unit 112: job 169032→169037,
unit 1026: none→169122). Output goes to the DFHack console like the
other devel/*-monitor tools.

[ab9rf]

A possibly useful note: handle_job_applications adds a crashlog minidump entry of type 0xf at the start of its processing and removes it at its end; this may be useful to deterministically determine when the job auction is in process.

I'm currently looking to see if there is an interposable vmethod we can use to hijack control during job auctions.

It typically takes us a few days after a DF release to locate worldst::handle_job_applications, at least in the Windows Steam edition (we don't normally analyze the Linux builds because decompiling gcc's output is much harder than decompiling MSVC's output). It's at 140d0d4d0 in DF 50.16 (Steam/Windows edition).

[Alistair-Afton]

Useful indeed — I have recorded the 0xf minidump marker and the handle_job_applications address in the job-assignment notes (DFHack/df_misc#90). For jobwatch purposes the minidump list is probably the cheapest deterministic auction-in-flight signal short of an interposable vmethod; if you do find a clean vmethod seam, a per-pass hook would make this tool (and any future job-assignment instrumentation) strictly better.

[ab9rf]

if you do find a clean vmethod seam, a per-pass hook would make this tool (and any future job-assignment instrumentation) strictly better.

I did spend some time looking for one but wasn't able to locate one, at least not yet.

One thing we've talked about is writing a tool that will run in a separate thread, periodically sample the crashlogger's "what am i doing" state, and generate a usage histogram so users can see what DF is spending the most time doing. The main problem with this right now is that we don't have a reliable way to find the crashlogger's state object (as it's unpublished). Maybe should ask @Putnam3145 if this variable can be exposed as a published global.