Use Bart's serial queue and consolidate publishing

[timshadel]

Pushing the work into a serial queue helps keep guarantees of completely processing events in-order. Simplifying the publishing into Subscription gives that concept weight and consistent use in the file.

[jarsen]

Cool! I'll have to give this a more thorough look through in a bit.

[jarsen]

So, @timshadel, can you or Bart remind me what issues you were running into that led to this?

[bwhiteley]

Some of the changes were prompted by the thread sanitizer.

In general, these changes make the behavior of the reactor consistent and predictable. Otherwise you don't know the state of the State (no pun intended) when reacting to an event. Also, you don't know what thread an command or event handler will be executed on (it's up to whoever triggered it).

Specifically I ran into this several times: within a react(to: I either triggered another event or fired a command (directly or indirectly). In the command or second event handler, the State was old while I would have expected it to have the results of the mutation caused by the original react(to:.

With this PR commands, event handlers, and updates are all executed on a proper queue, and the state of the State is more predictable and intuitive for each.

Maybe @timshadel and add some additional details for his motivation.

[timshadel]

My motivations are very similar to Bart's: guaranteed ordering and update safety. I've played around with it, and I can create scenarios where "last update wins", and the result isn't what you expected. This tends to happen only when it's used somewhat incorrectly, but there's no neon sign at the call site saying that you've done it wrong—everything almost works. With this slight change even that incorrect usage is guarded against.

While this isn't a design goal, this changes also gives you the freedom to actually issue events or commands as entry or exit actions that occur when you transition your state, and because they hit the serial queue, you still have all the safety of a pure update. Some events are more easily issued as something which happens when a state transition occurs rather than when an event occurs.

Anyway. Those are some ideas of what you get by putting it all in a queue.

[jarsen]

Sounds good and looks good. I'll get this all merged in. Thanks you two!