sched: Notification events have different meaning for each scheduler
As an example, KIST controls how much and when channel data is pushed on the network which means this wants to write event used by the Vanilla scheduler as "queued cell but no space on the outbuf" is not something that is coherent with KIST.
A channel is scheduled in when it has cells in the queue, then they are flushed one by one by the KIST scheduler until the kernel says "no more space". Then, that channel is put back in the channel pending list and will get handled at the next tick of KIST.
So, we really don't need KIST to be notified of this event from connection_flushed_some() which is used by Vanilla to try to flush more cells in the outbuf because the outbuf has room for it.
Where it is useful is the second callsite of that even in channel_tls_handle_state_change_on_orconn() which notifies the scheduler that it might be in need of flushing some stuff. In the case of a brand new channel just opening, its state is "IDLE" and that even will then put it in "waiting for cells" after.
That being said, what needs to happened:
-
Make the notification event a per-scheduler thing because KIST and Vanilla have different semantic for those events really. We should of course avoid as much as we can of code duplication and thus some "generic event handler" do make sense if they share the same semantic.
-
Add a "channel state is open" notification event instead of "wants to write" which is really only true in very specific cases in
channel_tls_handle_state_change_on_orconn(). That way, the scheduler can take a decision on the status of the channel instead of blind guessing it is waiting for cells. -
Nullify the "wants to write" event for KIST considering (2) so it stops possibly scheduling channels that do not need at all to be scheduled.