Add inspect-ready-q and inspect-scheduled-q HTTP API endpoints

[edgarsendernet]

Having the ability to quickly see queue configuration would be very helpful when managing and tuning KumoMTA. Parameters:

• queue name
• limit (the number of message spool IDs to return, default 50)

Response would contain:

• configuration values (queue config or egress_path config)
• next delivery time (for scheduled queues)
• array of message spool IDs in the queue. These could be used to fetch message data from inspect-message endpoint.

[wez]

The system is not optimized for that kind of per-message observation. To enable it will require data structure changes that will harm the maximum throughput of the system, which is undesirable.

The closest approximation would be to schedule some work to de-queue some number of messages from matching queue(s) and apply some function to them, and then re-insert them into the queues again afterwards.

You could sort of do this for yourself today using the rebind API and trigger_rebind_event = true to pass every message in the queue to a lua function. It's not an ideal match up today because there isn't really a way to share state, limit the number of matches or return scoped output from that event.

Querying other metadata about the queues overall is more easily doable without imposing a performance cost on the rest of the system.

[edgarsendernet]

I was thinking to implement this without changing the underlying timeq queues, as it's needed only when investigating something. Basic idea would be to clone the requested queue, then .skip() some amount of ms (maybe max message age) so that all the entries become due, and then return any entries up to specified limit. Not sure if that makes sense?