[fix]: drop invalidated sink events instead of crashing

[jamieQ]

Issue

the issue manifests in the following scenario:

1. an action is sent to node A
2. the subsequent re-render caused by handling the action removes node A from the tree, invalidating its EventPipe in the process
3. an observer of the WorkflowHost's rendering signal synchronously sends another event that propagates to node A when the rendering signal updates
4. action handling of this second event hits a fatal assertion because A’s event pipe has been marked as ‘invalid’

Changes

• removes the fatal assertion in favor of dropping the events and emitting debug console logging/regular assertions when this occurs
• adds a reentrancy check to differentiate when a sink is being used multiple times in the same call stack, likely due to UIKit doing synchronous things when Renderings are being updated but before action handling has fully unwound from the stack
• adds a regular assertion failure in the case an invalidated Sink is messaged when not in the re-entrant scenario
• updates tests

i asked around, and it seems that the Kotlin runtime has not enforced this hard assertion for some time, and i could not think of a compelling reason to continue doing it.

Checklist

• Unit Tests
• UI Tests (n/a)
• Snapshot Tests (iOS only) (n/a)
• I have made corresponding changes to the documentation (n/a)

[square-tomb]

Nice test!

[jbmorgan]

This should be pretty uncommon, right? Would it make sense to at least log to BugSnag if this happens in production?

[jamieQ]

yes i believe it's fairly uncommon, at least according to our existing bugsnag data. we don't actually currently have a straightforward mechanism to log errors/warnings to something listening from outside of this module, so that can be taken up as a follow-on task.