DRAIN_EXCLUSIVE_ACTIONS implementation

[steve-the-edwards]

Add an option to get the next action that is mutually exclusive to the dirty nodes. Then we can apply as many of those actions as possible.

Add tests for this as well and ensure existing tests can run with this runtime config on.

[zach-klippenstein]

I don't understand the interaction between conflation and drainExclusive. It looks like we run the drainExclusive loop first, then render, then conflate, drainExclusive, and render, etc. Wouldn't we want to continuously interleave drainExclusive and conflation passes? Or is that what we're doing and I just can't read code?

[zach-klippenstein]

At the risk of over-optimizing, this could be a value class to avoid allocating RenderingProduced objects every pass even when they're ignored.

[steve-the-edwards]

nice. will take a look at doing this.

[steve-the-edwards]

I'd have to talk more with you about what you are thinking. I am not sure we even need to report the rendering itself to the interceptor. I can start by just removing that?

[steve-the-edwards]

Well, that object is already allocated (probably why I was not worried originally). So we could start by just making RenderingProduced a value class I think I was confused originally because this comment was on the RuntimeUpdate sealed interface

[steve-the-edwards]

I made RenderingProduced a value class now. The others are just objects, so this should all be quite fast / have minimal allocations.

[zach-klippenstein]

Nit: You shouldn't need the backticks here, you're not using spaces or other illegal characters.

[steve-the-edwards]

It's actually because this is KMP code that runs on js as well, IIRC. For some reason the kotlin-js compiler can't handle long names that don't have ticks? Or maybe that's why I had to add the _. Now I can't remember. But it was something with kotlin-js.

[steve-the-edwards]

Turns out I was just remembering wrong or had copied this forward when not needed. Removed now!

[steve-the-edwards]

I don't understand the interaction between conflation and drainExclusive. It looks like we run the drainExclusive loop first, then render, then conflate, drainExclusive, and render, etc. Wouldn't we want to continuously interleave drainExclusive and conflation passes? Or is that what we're doing and I just can't read code?

the main loop (after the first synchronous render) is:

1. awaitAndApplyAction() for the first available action
2. DEA loop: Drain any exclusive actions immediately available - synchronously for any actions already queued (no suspend here).
3. render()
4. CSR loop: Drain any other actions immediately available; render() after each one.
5. pass updated rendering down the StateFlow.

No interleaving is necessary from what I can tell. The exclusive actions for DEA are just a subset of the actions that can be applied without rendering at all.