Ignoring implementation events

[alex-dixon]

Events generated by Precept's implementation rules are noisy, but filtering them from the event log presents some challenges. The crux is whether we represent "what happened" or "what happened that you care about" and which the numbering of states and events reflects.

Entire states can be comprised of ignored events. When they are we can either:
A. Ignore them: Not increment the state counter, drop the batch of events we've accumulated, and start the next session at the same state index
B. Use Null Object: send a "null object" for the log entry and advance the state counter normally

Pros ignore impl:
Users won't see "blank" states where nothing was added, nothing removed.
Event ordering will read as sequential.
Cons :
When user sets "Show impl facts/rules", the indexes will be different

Pros null object:
Users can configure whether to ignore impl layer and all state indexes would remain the same
Cons:
Ordering will be non-sequential in some way
Seeing 1 -2-4 or 1-2-3(impl only)-4 begs the question of where 3 is, or what happened at 3.

[alex-dixon]

This has been a recurring issue. There should be commit messages to that affect, both in precept core and this repo. We err on the side of not ignoring implementation-level events with the exception of those from macros and generated rules that perform intermediate calculations that the user would otherwise need to write out by hand (at the moment the ones we ignore are just for the entities macro which accumulates and groups all facts that match an eid in a list of user-provided eids. I'd like to make whether these events are ignored configurable both at the event-stream level in precept.core and through the UI in the visualizer so anyone who wants that information can have it if they want it.