Implement congestion_state_updated qlog event

[hfstco]

CC algorithms have different states and different implementations of these states.
RENO, CUBIC: SS, CA, Recovery
BBRv1: Startup, Drain, ProbeBW, ProbeRTT
C4: Initial, Recovery, Cruising, Pushing

In addition to the recovery_metrics_updated qlog event (already implemented), the qlog event draft specifies an congestion_state_updated event to log these states to a qlog file, even though the implementation of these states varies across CC algorithms.

qlog-quic-events-draft (version-00, as picoquic currently supports that version)

The current implementation of the CCs and qlog makes it difficult to implement this event, because the states and key parameters aren't accessible from the qlog code. There are two options to fix this:

1. Expose an API by the CC code to retrieve the current state and key parameters.
   There is already a picoquic_congestion_algorithm_observe function, but it only supports one parameter. And I don't know if it is suitable/intended to do this job.

2. Let the CC code call the qlog logging API itself.
   Is the solution I prefer, but we have to avoid blocking the execution due to writing to the qlog file.

[huitema]

"blocking the execution due to writing to the qlog file" is a general concern, not just with logging congestion state. It is mostly an issue during performance tests, when we want both precise logs and no impact. That's why I developed the "memory log" function, which can be used instead of qlog. It starts by allocating a big table of events in memory at the start of the process, then add events to the table as they happen until the table is full, and dumps the table in CSV format at the end of the process. But of course, we cannot do that for every process, too much memory required.

[huitema]

Of course, the issue with "memory log" is that it is a whole different system, parallel to qlog, for "almost the same results but not quite". I wonder whether we could unify them. Maybe have the qlog implementation write the qlog events in memory using some variant of sprintf, and then either write to the qlog file immediately in the general case, or wait until the end of the connection to dump the memory to disk. That would mean setting some kind of "logging option".

Of course, if we start having logging options, we could go further than just a "memory or disk" flag. For example, logging every packet inflates the size of the log. We could have an option to not do that, maybe only log the "interesting" packets. Maybe looking at the "log level" description in the revised qlog spec, see https://datatracker.ietf.org/doc/draft-ietf-quic-qlog-main-schema/.

[huitema]

On the design of the CC logging. Our current code is based on the V1 schema, from 5 years ago. The new version has a better definition of extensibility. The new spec separates recovery_metrics_updated and congestion_state_updated, while the current implementation lumps both types of data into recovery_metrics. I think the first step for addressing this issue would be to upgrade the code from the old version of qlog to the new one, then check how we implement the congestion_state_updated event.

In the new spec, the definition of the congestion_state_updated event is left to extensions. I suppose that the WG will eventually produce QLOG specifications for the common algorithms -- reno, cubic, bbr, maybe ledbat. Each of those would be a specific RFC. @hfstco, you may consider writing drafts for these. For new algorithms like C4, I suppose the authors need to propose a draft.