question: how should I schedule `lsquic_engine_process_conns()` to produce fuller `ea_packets_out` batches?

Nobody has claimed this yet.

I am adding udp gso to a nim binding for lsquic, and i wanted to check my understanding of the send path before continuing.

GSO only helps when a single `ea_packets_out` call contains several packets for the same peer. From the code, that seems uncommon once more than one connection is active:
- [`send_packets_out()`](https://github.com/litespeedtech/lsquic/blob/v4.7.0/src/liblsquic/lsquic_engine.c#L2774) takes one packet per connection each time around the iterator.
- [`coi_next()`](https://github.com/litespeedtech/lsquic/blob/v4.7.0/src/liblsquic/lsquic_engine.c#L2361) seems to return a different connection on each visit while several have data. it first drains a heap ordered by cn_last_sent, then rotates the active list.
- the accumulated batch is flushed when the iterator runs out of connections at [`end_for`](https://github.com/litespeedtech/lsquic/blob/v4.7.0/src/liblsquic/lsquic_engine.c#L2885), so one call to `lsquic_engine_process_conns()` sends whatever has accumulated by then.

if I understood that correctly, then with n connections sending, the batch tends to alternate between connections. you'd only see two packets for the same peer if the batch grows larger than the number of active connections. (pls correct me if i'm wrong)

Right now i call `lsquic_engine_process_conns()` from my read handler, so every incoming ack ends up triggering a tick and there isn't much chance for packets to accumulate.

my questions are:
- Did i understood the send path correctly?
- Is there a recommended pattern for when to call `lsquic_engine_process_conns()`? for example, should i drain several received datagrams before calling it, or rely more on the timer from `lsquic_engine_earliest_adv_tick()` instead of calling it once per read?
- does `es_max_batch_size` change this? from what i can tell it only affects the adaptive batch_size but wont make the batches more full when the connection iterator gets empty first

Thanks for any guidance

Start by tracing send_packets_out() and coi_next() in src/liblsquic/lsquic_engine.c, including the end_for section around the cited lines. Compare that flow with lsquic_engine_process_conns(), lsquic_engine_earliest_adv_tick(), and es_max_batch_size; done means documenting the recommended scheduling pattern and whether the batching assumptions are correct.

Written by the indexing model from the issue text.