Introduce Resolvable Conjunctions, Disjunctions ; Refactor resolvables

[krishnangovindraj]

What is the goal of this PR?

The reasoner views Conjunctions as a set of Resolvables. Because conjunctions are concepts in the lower 'pattern' domain and Resolvables are concepts from the higher logic domain, conjunctions do not store this mapping.

Since Resolvables nor Conjunctions have a reliable equality test, we rely on object identity and pass the objects themselves around when required. This is limiting in the reasoner - If we need the constituent concludables of a conjunction - we would need to pass them around with the conjunction.

We introduce a ResolvableConjunction class (and a corresponding ResolvableDisjunction class) to store the conjunction pattern and its concludables and refactor the reasoner to use these in place of the pattern.Conjunction class.

What are the changes implemented in this PR?

• Introduces ResolvableDisjunction & ResolvableConjunction class

• This holds the definitive mapping from a pattern.Conjunction to its constituent resolvables

  • the concludables which trigger rules, and
  • the maximally connected retrievables when the above rule-triggering concludables are excluded

• The Controllers & Processors are updated to use these in place of pattern.{Conjunction,Disjunction}

• Rules are also updated to use these in Conclusion & Condition.

• Moves the logic for extracting the set of Concludables & Retrievables to the ResolvableConjunction class

• This change cascades into all the Resolvable tests

[grabl]

PR Review Checklist

Do not edit the content of this comment. The PR reviewer should simply update this comment by ticking each review item below, as they get completed.

---

Code

• [x] Packages, classes, and methods have a single domain of responsibility.
• [x] Packages, classes, and methods are grouped into cohesive and consistent domain model.
• [x] The code is canonical and the minimum required to achieve the goal.
• [x] Modules, libraries, and APIs are easy to use, robust (foolproof and not errorprone), and tested.
• [x] Logic and naming has clear narrative that communicates the accurate intent and responsibility of each module (e.g. method, class, etc.).
• [x] The code is algorithmically efficient and scalable for the whole application.

Architecture

• [x] Any required refactoring is completed, and the architecture does not introduce technical debt incidentally.
• [x] Any required build and release automations are updated and/or implemented.
• [x] Any new components follows a consistent style with respect to the pre-existing codebase.
• [x] The architecture intuitively reflects the application domain, and is easy to understand.
• [x] The architecture has a well-defined hierarchy of encapsulated components.
• [x] The architecture is extensible and scalable.

[krishnangovindraj]

This is currently on hold for a further refactor - Ideally, Rules would not cache ConcludablesTriggeringRules (or Retrievables) and require the logic to invalidate these cached when the rule-graph changes. All such caching responsibilities should be assigned to the LogicCache object.