What is the Problem Being Solved?

The contextualized slog sender generates a high level trigger type based on the source of the inbound trigger (timer poll, bridge inbound, kernel update event, etc.)

For bridge inbound triggers we could benefit from further classifying the type of action, and recording that on the trigger context for later querying. @warner wrote a pretty good classifier in python, and it should be pretty easy to port that to the contextual slog sender.

Description of the Design

Port the classify-runs logic to classify the run, and add a run.trigger.classification field to the triggerContext.

Since we now include body of the bridge action, or other source type info in the inbound slog event, there should no longer be a need to wait for the first delivery in the run to classify the run itself.

Security Considerations

None

Scaling Considerations

None, telemetry only. It would simplify queries we make in the future against classified runs.

Test Plan

Manual on mainnet slog activity

Upgrade Considerations

Slog sender are part of the chain software upgrade but we can technically use new or updated ones dynamically through config.