Dead code path for serializing activations

[WilliamParker]

Continuing a conversation from #482 (comment) :

@k13gomez looking back at this I don't think there's any current code path that would lead to a RuleOrderedActivation being serialized. They are stored in the memory in a queue when a ProductionNode is activated here indicating that a rule RHS has activated. These activations are then removed from the queue in the fire-rules loop. However, after the changes in #268 nothing actually happens in the rule network when facts are inserted or retracted; rather, these operations are queued pending a fire-rules call. For an insertions this happens here in the current code. Therefore a RuleOrderedActivation won't exist until fire-rules is called. However, the fire-rules loop won't exit while activations are pending - as long as activations are pending, the rules network may not have reached logical consistency. So I think there is some dead code here in durability that could be removed such as this.

@mrrodriguez any thoughts?

[k13gomez]

@WilliamParker this makes sense, so then there's opportunity to remove the https://github.com/cerner/clara-rules/blob/d9b2fc998e5c034486b29999b4269e379378e817/src/main/clojure/clara/rules/durability.clj#L336 as well as some unused serialization handlers, even though they are now fixed, if they are unused I don't see reason to keep them around. I will also double check the durability tests to ensure we have enough tests that verify that serializing/deserializing the rules session before / after fire rules yields the same results after fire rules.