Emit YAML for events cachemgr report

[kinkie]

Also EventScheduler::dump to be stream-based,
and simplify TestEvent::testDump

[kinkie]

Single-worker output in master:

Last event to run: MaintainSwapSpace

Operation                   Next Execution  Weight  Callback Valid?
logfileFlush                0.039 sec       1    yes
MaintainSwapSpace           0.039 sec       1    N/A
fqdncache_purgelru          2.429 sec       1    N/A
ipcache_purgelru            7.531 sec       1    N/A
memPoolCleanIdlePools       13.968 sec      1    N/A
statAvgTick                 38.488 sec      1    N/A
peerRefreshDNS              100.777 sec     1    N/A
peerClearRR                 216.965 sec     0    N/A
netdbSaveState              1711.270 sec        1    N/A

Output with PR applied:

last event to run: MaintainSwapSpace
scheduled events:
  - operation: logfileFlush
    secs to next execution: 0.424
    weight: 1
    callback valid: yes
  - operation: MaintainSwapSpace
    secs to next execution: 0.438
    weight: 1
    callback valid: N/A
  - operation: fqdncache_purgelru
    secs to next execution: 4.427
    weight: 1
    callback valid: N/A
  - operation: memPoolCleanIdlePools
    secs to next execution: 4.427
    weight: 1
    callback valid: N/A
  - operation: ipcache_purgelru
    secs to next execution: 9.428
    weight: 1
    callback valid: N/A
  - operation: statAvgTick
    secs to next execution: 49.413
    weight: 1
    callback valid: N/A
  - operation: peerClearRR
    secs to next execution: 289.391
    weight: 0
    callback valid: N/A
  - operation: peerRefreshDNS
    secs to next execution: 2973.609
    weight: 1
    callback valid: N/A

[kinkie]

This PR has not adopted spaces() from PR #1735 yet

[rousskov]

Please settle spaces() issue before posting any new YAML PRs or requesting additional reviews on the already posted ones. Squid currently lacks the necessary foundation for new YAML PRs, and we have enough information to provide that foundation.

[rousskov]

Just like in other reports you have already converted, please do not report fields that are not applicable to an event. It was difficult or even wrong to skip a field when this was a table. This PR is no longer using a table, removing that obstacle.

[kinkie]

I am obviously biased, for me spaces() can go in as-is. What do I need to do to convince you that it's good enough? Right now I have a backlog of completed changes; using a local variable is to me a way to minimize the changes to redo over once spaces() lands, please advise if you have any idea on how I can keep myself unblocked otherwise

[kinkie]

Just like in other reports you have already converted, please do not report fields that are not applicable to an event. It was difficult or even wrong to skip a field when this was a table. This PR is no longer using a table, removing that obstacle.

Removed in 553a97b

[rousskov]

for me spaces() can go in as-is. What do I need to do to convince you that it's good enough?

This PR is not the right place to discuss problems with spaces().

Right now I have a backlog of completed changes

Please do not interpret my commends below as an implicit agreement with the above "completed" characterization of any pending changes.

Creating more and more non-urgent PRs (or code branches, etc.) that heavily depend on some pending issue resolution will naturally grow that backlog, especially when the exact resolution of that issue is unknown and may impact all those changes quite a bit!

BTW, creating lots of PRs that fix a duplicated issue in a new/untested way is likely to face very similar problems.

I cannot stop new PRs, but I do not understand why keep creating all that extra work/overhead.

please advise if you have any idea on how I can keep myself unblocked otherwise

My recommendation is to work towards spaces() resolution. If you have free time after that, pick a non-YAML problem that does not depend on spaces() resolution.

[kinkie]

This is ready to review, using a local indent SBuf instead of spaces() while waiting for spaces to land. But apart from that bit of rework, I don't have any outstanding requests for change

[rousskov]

Please avoid unnecessary abbreviations, especially non-standard ones.

Suggested change

	indent << indent << "secs to next execution: " << std::setprecision(3) << std::fixed << (e->when? e->when - current_dtime : 0) << '\n';
	indent << indent << "seconds to next execution: " << std::setprecision(3) << std::fixed << (e->when ? e->when - current_dtime : 0) << '\n';

Many of these events wait for hours. I recommend removing "seconds" from the item key so that we can easily change it later, when we improve support for time units:

Suggested change

	indent << indent << "secs to next execution: " << std::setprecision(3) << std::fixed << (e->when? e->when - current_dtime : 0) << '\n';
	indent << indent << "next execution in: " << std::setprecision(3) << std::fixed << (e->when ? e->when - current_dtime : 0) << " seconds\n";

... or something like that.

Finally, many of these events do not repeat so "next" is quite misleading here. I would rephrase further to avoid the (often wrong) implication (e.g., "runs in ... seconds" or "scheduled to run in ... seconds").

[kinkie]

... seconds, from the YAML schema perspective, turns the field from a number into a string, requiring additional work for automations.
In fact, in an ideal world I would specify the unit in a comment for the benefit of humans only: specifying it in the key means that if we change time unit the key changes

[kinkie]

we can use an inline comment: next execution in: ... # seconds

[rousskov]

... seconds, from the YAML schema perspective, turns the field from a number into a string, requiring additional work for automations.

I strongly disagree with the implication that consuming unitless numbers (or dealing with field key changes) is overall better "for automations" than consuming numbers with units (because the latter requires "additional work"). And since lots of Squid report fields do use units of various kinds, and using units often makes reports more readable for humans, that "additional work" will most likely be required anyway and will be amortized across various consumed reports.

In fact, in an ideal world I would specify the unit in a comment for the benefit of humans only:

Our ideals differ: Ideally, as a consumer application developer, I would want units to be correctly processed by my code rather than hidden from it in a YAML comment, especially if units change based on the reported value (to assist human readers).

specifying it in the key means that if we change time unit the key changes

Agreed. The unit should not go into the field key, especially when the unit should change based on the reported value (for human benefit). That is why I explicitly recommended removing PR-added seconds from the field key.